Repository navigation
Alert on webhook job wait time instead of Celery queue length - #148
Merged
Merged
Conversation
The dispatcher deliberately holds the Celery queue at dispatcher_max_celery_queue during bursts, so erroring whenever it exceeded that fired constantly (CHRONOS-3R) without indicating a real problem. Log an error when a dispatched job waited longer than dispatcher_max_job_wait_seconds instead, and cap each dispatch cycle to the headroom left under the ceiling so it can't overshoot. Fixes CHRONOS-3R Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Move the wait check out of dispatch_cycle into check_job_wait(), run by the dispatcher at most once a minute and before the backpressure check, so stalled workers still alert and a backlog logs one error a minute, not one per job. - Keep the queue-length error in task_send_webhooks at celery_queue_alert_length (1000) so producers that bypass the dispatcher (Bobbin, use_round_robin=False, retries) are still covered. - Make batch_limit a job_dispatcher_task parameter. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
Summary
CHRONOS-3R ("Queue is too long") has fired ~7k times since June without a real incident. The error threshold in
task_send_webhookswas the same number as the dispatcher's backpressure ceiling (dispatcher_max_celery_queue= 100), and the dispatcher deliberately holds the Celery queue at that ceiling whenever the branch queues have a backlog. Any small overshoot (retries, a multi-branch cycle) tripped it: ~85% of events in the last 30 days were qlength 101–110, and the max was ~210.The regular trigger is TC2's 3-hourly
update_agency_paid_invoice_milestone_datesjob, which sends ~1,120 webhooks for branch 183 (Hermes) at :34 past every third hour. The round-robin is doing its job: over the last 7 days, other branches' p95 lag from Chronos ingest to send during those bursts was ~9s, while branch 183's own was ~74s.What we did
check_job_wait()finds the oldest head job across the branch queues and logs an error when it is older thandispatcher_max_job_wait_seconds(300s). The dispatcher calls it at most once a minute and before the backpressure check, so stalled workers still alert and a long backlog logs one error a minute rather than one per job.task_send_webhooksnow errors only abovecelery_queue_alert_length(1000), which still covers producers that bypass the dispatcher (Bobbin,use_round_robin=False, retries). The observed max is ~210, so this is silent today.dispatcher_max_celery_queue.batch_limitis now ajob_dispatcher_taskparameter like the others.Out of scope
COMPANY_SYNCABLE_FIELDSin hermesapp/tc2/process.py), so sending only when pay dates change would stop the other fields syncing. Draft exploring it: tutorcruncher/TutorCruncher2#17921.Fixes CHRONOS-3R
🤖 Generated with Claude Code