Repository navigation
docs(operations): read the drill verdict off requestedAt, not the run id - #135
Merged
Merged
Conversation
A coalesced wake is listed against the run that absorbed it, so the recovery wake and that run share a run id. Matching rows by id therefore lands on the earlier wake's row, which reads `coalesced: 0` - and the drill looks like it exercised the recovery path when it did not. Match on requestedAt against the `woke ...` line in the green run's log instead. Records what the three drills so far do and do not prove, and why same-ticket coalescing is safe in production: wake admission is decided against that issue's execution lock, so a run live for the same agent on another ticket cannot absorb a recovery wake. Co-Authored-By: Daedalus <daedalus@agents.flopbut.local> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 58 minutes. View limit detailsLimit details: You’ve used the included review currently available. Review configuration: ⚙️ Run configuration
📒 Files selected for processing (1)
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 |
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.
Follow-up to #134, from auditing the drill it documents.
A coalesced wake is listed against the run that absorbed it, so the recovery wake and that run share a run id. Matching the diagnostics rows by run id therefore lands on the earlier wake's row, which reads
coalesced: 0, and the drill looks like it exercised the recovery path when it did not. On the third drill pair the recovery wake (requestedAt 09:21:58, matching the green run'swoke …line) isstatus: coalesced, coalescedCount: 1, folded into a run created by a 09:21:51 wake the pager did not send. The row cited as proof was that 09:21:51 wake.What the drill still proves, and what the docs now say instead: the alert closed unattended, and the raise path cannot have done it (its assignment run finished 2m12s before the wake existed). What no drill has caught yet is the recovery wake starting a run - the ordinary production shape.
Also records why same-ticket coalescing is safe in production rather than leaving it as an assumption: wake admission is decided against that issue's execution lock, so a run live for the same agent on another ticket cannot absorb a recovery wake.
Docs only.
bash scripts/page-cotel-health_test.sh38 pass / 0 fail.Co-Authored-By: Daedalus daedalus@agents.flopbut.local
Co-Authored-By: Claude Opus 5 noreply@anthropic.com