A five-minute lease column handles both retry backoff and crash recovery

The lease is one column with two behaviours. Claiming a job stamps it five minutes into the future ^[6]. A worker that dies mid-call stops writing, the stamp passes, and the next tick sees the row as claimable again ^[6]. There is no reaper process and no dead-letter topic to drain. After three failed attempts the job is marked failed and the item it was moderating goes to a human ^[7].

The same column explains a row that looks broken. Four jobs sat at one attempt and still pending; those were the batch in flight under a live lease ^[13].

Ten a minute is a budget number. The three job kinds together stay under the model's per-minute allowance on the author's tier, and because every kind draws from the same allowance the worker takes the oldest ten and ignores what they are ^[8]. That pacing transfers to another pipeline only if the model budget and the job mix match; on a tier with a larger per-minute allowance, the same code would drain the same queue faster ^[8].

Six minutes in, the done counts were 28 places, 27 content and 0 images, which is 55 jobs against a ceiling of 60 ^[9][1]. Pending was 151 plus 152 plus 18, or 321 jobs, about 32 more minutes at ten a minute ^[2][3]. "The worker was doing exactly what it was built to do, and it was going to take another half hour," the author wrote ^[10]. The two report-level kinds each show 179 rows for a burst of 178 reports, and the post does not account for the extra one ^[4].

The image count is where the older bug shows. Only 18 image jobs were queued out of a two-year photo set, because the trigger enqueues only photos still marked pending, and roughly a hundred of this traveller's photos already carried needs review ^[5].

Ninety-eight of those rows gave the same reason: Image moderation service unavailable ^[17]. One code path writes that string, the image moderation function, on the final of three failed attempts, so the model never returned a judgement on them ^[18]. Two rows carried the model's own words, "a child as the main subject" and "an unclear private space" ^[19].

The failures predate the queue. At import time, every photo insert called the model directly ^[21]. The import wrote hundreds of photos in minutes and the model rate-limited the burst; three attempts, three refusals, and each photo was parked as needs review ^[21]. The job rows were already gone, since finished jobs are purged after seven days ^[20]. Weeks later the publish trigger went looking for pending photos and skipped them ^[22]. "A pipeline failure had been stored in the same field as a verdict, and from then on it was treated as one," the author wrote ^[23].

The HTTP log showed the call to the worker timing out after five seconds, every minute, because the cron does not wait for an answer the worker takes up to sixty seconds to produce ^[14]. The author checked the cron's own run log instead: one run a minute, every minute, all succeeded ^[15].

The queue protects the model's budget and the request path. It does nothing for the next author in line. A report published during the burst waits behind it, which the author calls fine for a one-off import and not fine for a live site; the fix he names is a second worker, or a share of each tick reserved per job kind ^[11]. "I will build it the day the queue shows me it is needed, not before," he wrote ^[12].