Four-tier queue priority scheme for prerender jobs (CS-11758)#5397
Four-tier queue priority scheme for prerender jobs (CS-11758)#5397habdelra wants to merge 3 commits into
Conversation
…-11758) Priority is a worker-reservation floor: a worker dequeues only jobs at or above its configured minimum, oldest-first among those. The tiers: 10 any user-initiated job 9 user-initiated prerender-html (reserved; no producer yet) 1 any system-initiated job 0 system-initiated prerender-html (reserved; no producer yet) - systemInitiatedPriority moves 0 -> 1 so the future system prerender-html tier (0) sits below all indexing work - normalizeQueueJobSpec's implicit default follows the system tier - daily-credit-grant cron enqueue joins the system tier (was a stray 4) - worker-manager: high-priority pool floor drops 10 -> 9 so it will also serve user-initiated prerender-html; new --indexPriorityCount pool floors at 1 (never serves system prerender-html); all-priority pool floor pinned at 0, unchanged semantics - start scripts pass --indexPriorityCount from WORKER_INDEX_PRIORITY_COUNT (default 0, so this is inert until deployment config sets it) Inert until prerender-html jobs exist: the high-priority pool at floor 9 still only sees priority-10 jobs, floor-0 workers continue to process everything (including jobs enqueued at the old system priority), and system jobs at 1 remain servable by every non-high pool. No dequeue site filters on exact priority values (verified: pg-queue uses >=, the indexing dashboard displays priority raw). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Preview deploymentsHost Test Results 1 files ±0 1 suites ±0 2h 38m 5s ⏱️ + 1m 1s Results for commit de9a062. ± Comparison against earlier commit 2ea3ce8. Realm Server Test Results 1 files ±0 1 suites ±0 10m 2s ⏱️ +31s Results for commit de9a062. ± Comparison against earlier commit 2ea3ce8. |
…html tier The worker fleet stays two categories: the all-priority pool serves jobs of any priority number, and the high-priority pool serves the user-initiated tiers (floor userInitiatedPrerenderHtmlPriority). No per-pool count or deployment configuration changes are needed for the tier scheme. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Introduces a four-tier job-priority scheme for the shared queue so prerender-html work can share infrastructure with indexing while remaining reservable to specific worker pools (via a dequeue “floor” rather than strict priority ordering).
Changes:
- Defines new queue priority tiers (10/9/1/0), moves
systemInitiatedPriorityfrom0→1, and defaults unspecified publishes to the system tier. - Updates worker pool floors so the “high priority” pool can serve future user-initiated prerender-html (>=9) while never touching system-tier work.
- Updates cron enqueue priority and refreshes documentation/comments to align with the new scheme.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| README.md | Updates local-dev docs to describe worker pools in terms of “regardless of priority” rather than “system vs user initiated”. |
| packages/runtime-common/worker.ts | Adjusts JobInfo comment to refer to tier constants in queue.ts rather than hardcoded numeric meanings. |
| packages/runtime-common/queue.ts | Adds four-tier priority constants, updates default publish priority, and documents the tier model. |
| packages/runtime-common/prerender-headers.ts | Updates priority-header docs (but still needs a small correction per comment). |
| packages/runtime-common/definition-lookup.ts | Updates docs to reference tier constants instead of hardcoded numbers. |
| packages/realm-server/worker-manager.ts | Switches worker minimum-priority floors to the new prerender-html tier constants; updates CLI help text. |
| packages/realm-server/lib/cron-scheduler.ts | Enqueues daily-credit-grant at systemInitiatedPriority. |
| packages/host/app/services/store.ts | Updates explanatory comments about priority propagation to avoid hardcoded “0/10” semantics. |
| docs/aws-operations.md | Refreshes operational runbook wording and fixes markdown table formatting. |
| .claude/skills/prerender-sizing/SKILL.md | Updates the prerender-sizing skill docs (mostly formatting + tier references). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Update the diagnostics/header/visit comments that still described the old 0/10 meaning: the job-priority header's valid range bottoms out at the lowest tier (0), background indexing runs at systemInitiatedPriority (1) not 0, and the render-timeout/manager defaults are the lowest tier rather than 'system priority'. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Queue job priority is a worker-reservation floor: a worker dequeues only jobs whose priority is at or above its configured minimum, oldest-first among those. A higher number therefore reserves a job to more (and to more-dedicated) worker pools. This PR introduces the four-tier scheme that lets prerender-html work ride the same queue as indexing without competing with it:
10910The prerender-html tiers sit one notch below their initiator tier so a pool's floor can take in an initiator's plain jobs with or without its (orders-of-magnitude slower) HTML rendering work. No producer of the
9/0tiers exists yet — those constants are reserved for the prerender-html job.What this changes:
systemInitiatedPrioritymoves from0to1, and a publish that doesn't state a priority now lands on the system tier. Thedaily-credit-grantcron enqueue joins the system tier as well (it previously used an off-scale value).userInitiatedPrerenderHtmlPriority = 9andsystemInitiatedPrerenderHtmlPriority = 0.9instead of10, so once a producer emits user-initiated prerender-html jobs, the pool that guarantees user-facing latency serves them too — and still never touches system-tier work. The all-priority pool continues to serve jobs of any priority number.Behavior today is unchanged: the high-priority pool at floor
9sees only priority-10jobs until something emits9s, all-priority workers continue to process everything (including jobs already sitting in the queue at the former system priority), and system jobs at1remain servable by every pool that could serve them before. No dequeue site filters on an exact priority value: the queue's claim query usespriority >=, and the indexing dashboard displays the number raw. The page pool's high-priority threshold (deployed at5) still sits strictly between the system tiers (0/1) and the user tiers (9/10). No deployment configuration changes are needed.Existing queue, coalescing, and endpoint tests cover the moved constant (the startup-indexing test asserts
systemInitiatedPriorityvia the constant); floor mechanics are exercised by the worker-priority queue tests with explicit values on both sides.