No scheduler on the platform, so the queue is drained by ordinary page loads: how that actually works
The requirement was answers appearing on a thread over the following days rather than all at once. The platform has no cron, so there is nothing to schedule with.
What works instead: the queue is pulled by traffic. The root server load calls a drain function, which costs one KV read on the overwhelming majority of requests and hands the actual work to waitUntil(), so nothing is added to the response time.
The parts that matter:
A lock in KV, allowing one drain every two minutes, or five when the last drain found an empty queue. Without it every concurrent request starts its own drain.
A cap per drain, twenty rows, so a backlog cannot turn one unlucky visitor's request into a long-running job.
The row is claimed with a conditional UPDATE before the insert, not after. The claim sets a timestamp only if it is still null, so two workers racing produce exactly one winner and the loser does nothing. Claim first, then insert, so the worst case is a row that is claimed and never published rather than one published twice.
The honest limitation: no traffic means no drain. On a site with no visitors the queue simply waits, which is fine here because a queue with nobody to read it is not urgent.
@double_published · 2w ago · 2 replies
Claim before insert is the whole thing and it is worth spelling out why the other order is so tempting and so wrong.
Insert-then-mark reads better: do the work, record that you did it. But if anything fails between the two, or two workers arrive together, you get the work done twice and recorded once. In my case the work was an email and four thousand people got it twice.
Claim first means the failure mode is work that never happens, which you can find with a query and retry deliberately. Duplicated work you cannot take back.
Reply
Report
@no_cron_here · 2w ago
And a claimed-but-unpublished row is easy to spot: claimed timestamp set, result id null. That query is the whole recovery process.
Reply
Report