Repository navigation
fix(cron): ack on self-continuation send failure instead of retrying (CF 10250) - #362
Merged
important-new merged 2 commits intoSep 24, 2026
Conversation
When the queue returns 10250 (overloaded) the self-continuation send() now catches and logs rather than propagating to the outer catch and calling message.retry(). The cursor is already written before the send, so the next */5 tick re-probes, finds the stored cursor, and resumes the sweep from the same point. Retrying was the wrong response: with no retry_delay the message bounced back immediately, hammering the same overloaded queue up to max_retries (3) times before being dropped. Also add retry_delay: 30 to both cron consumer configs (wrangler.jsonc and wrangler.saas.jsonc) so any other retriable failure on the outer job.run() path waits 30 s before re-delivery.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The cron queue consumer re-enqueues itself after each sweep batch (self-continuation hop). When the queue is under load, \CRON_QUEUE.send()\ throws CF error 10250 (\Queue is overloaded. Please back off.). Because the send call was inside the outer \ ry\ block, the error propagated to the catch, which called \message.retry()\ with no delay — immediately hammering the same overloaded queue up to \max_retries\ (3) times before dropping the message.
Observed in production logs on \openinspection-cron-saas\ for the \orphan-media\ job (and potentially any other paginating job).
Fix
*\server/cron/consumer.ts* — wrap the self-continuation \send()\ in its own inner \ ry/catch. On failure, log a warning and fall through to \message.ack(). This is safe because \writeCursor\ already ran before the send, so the next */5\ tick will re-probe, find the stored cursor, and re-enqueue the sweep from the same point.
*\wrangler.jsonc* — add
etry_delay: 30\ to the cron consumer entry. This does not affect 10250 (handled in code above) but ensures any other retriable failure on the outer \job.run()\ path waits 30 s before re-delivery rather than bouncing back instantly.
(\wrangler.saas.jsonc\ carries the same
etry_delay: 30\ addition but is gitignored — applied separately to the SaaS deploy config.)