Summary
The self-monitoring "review burst" anomaly detector has repeatedly flagged the same PRs (JSONbored/loopover, /metagraphed, /awesome-claude) for publishing 6+ review surfaces within 2 hours with no real state change (Sentry: ops_anomaly, LOOPOVER-21/22/23/1W). #6724 already added byte-identical no-op detection for the comment and label outputs, but its own comment explicitly flagged gate_check_run as "a separate, not-yet-implemented scope" — for any repo with the gate check enabled (the common case), gate_check_run's mere presence in a pass's published outputs unconditionally counts as "the surface changed," even when the gate's actual conclusion is byte-identical to the last time this exact commit was reviewed.
Area
GitHub App
Expected behavior
A re-review pass over an unchanged commit (same head SHA) that produces the exact same gate conclusion as the last completed check for that head should not count as a fresh pr_public_surface_published.
Actual behavior
surfaceContentChanged (src/queue/processors.ts) treats gate_check_run's presence in publishedOutputs as an unconditional change signal, so a stuck-CI-finalize loop or retry storm that keeps re-triggering a review of the same commit inflates the review-burst counter every time, even with a stable verdict.
Validation
Confirmed via the closed #6724 PR's own test file comment ("Extending a similar no-op signal to gate_check_run is a separate, not-yet-implemented scope") and by reading the current surfaceContentChanged computation, which still treats any non-comment/label output as an unconditional change.
Summary
The self-monitoring "review burst" anomaly detector has repeatedly flagged the same PRs (JSONbored/loopover, /metagraphed, /awesome-claude) for publishing 6+ review surfaces within 2 hours with no real state change (Sentry:
ops_anomaly, LOOPOVER-21/22/23/1W).#6724already added byte-identical no-op detection for the comment and label outputs, but its own comment explicitly flaggedgate_check_runas "a separate, not-yet-implemented scope" — for any repo with the gate check enabled (the common case),gate_check_run's mere presence in a pass's published outputs unconditionally counts as "the surface changed," even when the gate's actual conclusion is byte-identical to the last time this exact commit was reviewed.Area
GitHub App
Expected behavior
A re-review pass over an unchanged commit (same head SHA) that produces the exact same gate conclusion as the last completed check for that head should not count as a fresh
pr_public_surface_published.Actual behavior
surfaceContentChanged(src/queue/processors.ts) treatsgate_check_run's presence inpublishedOutputsas an unconditional change signal, so a stuck-CI-finalize loop or retry storm that keeps re-triggering a review of the same commit inflates the review-burst counter every time, even with a stable verdict.Validation
Confirmed via the closed
#6724PR's own test file comment ("Extending a similar no-op signal to gate_check_run is a separate, not-yet-implemented scope") and by reading the currentsurfaceContentChangedcomputation, which still treats any non-comment/label output as an unconditional change.