docs: document releasing; make worker-live tolerant of a slow deploy - #45
Conversation
worker-live's window was one number doing two jobs: waiting for a deploy and declaring failure. Tuned to a single observed deploy, it could only trade false alarms against slow detection — and it had already produced one false alarm, which is the kind of thing that teaches people to re-run a check reflexively, including the time it is right. Split into DEADLINE_MS (20m, when to fail) and SLOW_MS (8m, when to notice). A deploy that lands late but correct now passes and emits a notice, so a gradual slowdown shows up as a trend rather than arriving one day as a red check. timeout-minutes moved 15 -> 25: leaving it at 15 would have let the job be killed before the script's own diagnosis printed, replacing a useful message with an opaque timeout. The failure text now distinguishes the two conditions it can report. "The deploy has not landed" and "the endpoint serves the wrong bytes" send people to different places, and the digest checks further down are what detect the latter. README gains a Releasing section — the process is now one action and the front page did not say so — and drops a stale line implying a tag moves the endpoint. It does not: the release publishes artifacts, and a separate reviewed PR repoints the pins. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
get-resq-software | 0df008c | Aug 11 2026, 06:42 AM |
|
Warning Review limit reached
Next review available in: 32 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Closes the last of the three items I flagged as deliberately left open.
worker-live: one number was doing two jobs
The window both waited for a deploy and declared failure, so tuning it could only trade false alarms against slow detection. It was fitted to a single observed deploy — and had already produced one false alarm, which is how people learn to re-run a check reflexively, including the time it is right.
SLOW_MSDEADLINE_MStimeout-minutesA deploy landing late but correct now passes and emits a notice, so a gradual slowdown surfaces as a trend instead of arriving one day as a red check.
timeout-minuteshad to move with it. At 15 the job would have been killed before the script's own diagnosis printed, replacing a useful message with an opaque timeout — the same class of mistake as the>/dev/nullthat swallowed the tag-creation error. Asserted in the PR checks thatSLOW < DEADLINE < job timeout.The failure text now separates the two conditions it can report. "The deploy has not landed" and "the endpoint serves the wrong bytes" send people to different places, and the digest checks further down are what detect the latter — so the timeout message says so explicitly rather than implying corruption.
README
Adds a Releasing section. The process is now a single action and the front page did not say so:
Also drops a stale line implying a tag moves the endpoint. It does not: the release publishes artifacts, and a separate reviewed PR repoints the pins. The two-gate table makes that explicit, since it is the thing most likely to be misread.
Verified: YAML valid, embedded JS parses, heading structure intact.
🤖 Generated with Claude Code