Context
The review-burst anomaly rule (src/review/ops-wire.ts, added in #3766) counts github_app.pr_public_surface_published audit events via findHottestReviewTargetForRepo -- which are only recorded on a COMPLETED publish pass, after a review actually finishes and posts a surface. The incident #3747 fixed (13 subscription_cli_timeout failures across 8 PRs in a 47-minute window, each SIGKILLed mid-generation with zero output, re-swept and re-billed every ~2 minutes) produces exactly ZERO publish events per failed attempt -- a timed-out/SIGKILLed call never reaches the publish-event audit write.
So the review-burst rule -- built in direct response to that incident -- would show a flat/zero burst count for the PR throughout the entire incident, even though tokens were being burned on every failed retry. It measures successful-republish frequency, not attempt/failure frequency, and structurally cannot see the exact incident class that motivated building it.
(Also note: GITTENSORY_REVIEW_OPS is currently "false" in production, so this rule isn't running at all today -- this issue is about its detection logic being incomplete even once it's turned on, independent of that separate enablement decision.)
Requirements
- Add a companion signal to the review-burst rule keyed on
ai_usage_events rows with a non-ok status (or an equivalent failed-attempt audit event), not just the publish ledger.
- Preserve the existing publish-frequency signal as-is (it catches a different, still-valid incident shape: excessive successful re-reviews of an unchanged PR).
Deliverables
Acceptance criteria
- A synthetic repeat-failure-with-zero-publishes scenario trips the review-burst rule.
- The existing repeat-success scenario still trips it too (no regression).
Parent: #1667
Context
The review-burst anomaly rule (
src/review/ops-wire.ts, added in #3766) countsgithub_app.pr_public_surface_publishedaudit events viafindHottestReviewTargetForRepo-- which are only recorded on a COMPLETED publish pass, after a review actually finishes and posts a surface. The incident #3747 fixed (13subscription_cli_timeoutfailures across 8 PRs in a 47-minute window, each SIGKILLed mid-generation with zero output, re-swept and re-billed every ~2 minutes) produces exactly ZERO publish events per failed attempt -- a timed-out/SIGKILLed call never reaches the publish-event audit write.So the review-burst rule -- built in direct response to that incident -- would show a flat/zero burst count for the PR throughout the entire incident, even though tokens were being burned on every failed retry. It measures successful-republish frequency, not attempt/failure frequency, and structurally cannot see the exact incident class that motivated building it.
(Also note:
GITTENSORY_REVIEW_OPSis currently"false"in production, so this rule isn't running at all today -- this issue is about its detection logic being incomplete even once it's turned on, independent of that separate enablement decision.)Requirements
ai_usage_eventsrows with a non-okstatus (or an equivalent failed-attempt audit event), not just the publish ledger.Deliverables
src/review/ops-wire.ts(or wherever it's cleanest) counting failed/retried attempts per PR within the burst window.Acceptance criteria
Parent: #1667