The ops-anomaly detector (src/review/ops-wire.ts) flags a "review burst / stuck-CI finalize loop" when a PR accumulates >= 6 github_app.pr_public_surface_published audit events within 2 hours (findHottestReviewTargetForRepo, src/db/repositories.ts). Confirmed live on 2026-07-16: JSONbored/loopover#6641 (6 publishes) and JSONbored/metagraphed#6264 (22 publishes).
Root cause: an external CI system flapping (queued -> completed -> re-queued...) on the same head SHA causes the finalize pipeline to legitimately re-run and publish each time ci.hasVisiblePending reads false. createOrUpdateIssueCommentWithMarker (src/github/comments.ts) already dedupes the actual GitHub PATCH when the rendered comment body is byte-identical -- but that dedup is invisible to the audit/metrics layer, which unconditionally records pr_public_surface_published and pushes to publishedOutputs regardless of whether the GitHub-facing content actually changed (src/queue/processors.ts ~8470, ~10573).
The existing #regate-churn no-op guard (processors.ts ~9728-9744) does NOT generalize to fix this: it's deliberately scoped to publicSurface: "off" (check-run-only) repos, per its own comment -- lastPublishedSurfaceSha is documented as "reporting/diagnostic state, not a hard scheduled-sweep skip" because a comment can be stale/partial even when the head marker matches. Blindly extending that guard to comment/label-surface repos (loopover/metagraphed's normal mode) risks silently skipping a genuinely-needed republish.
Correct fix, scoped to the metrics layer, not the publish-decision logic: thread createOrUpdateIssueCommentWithMarker's existing no-op/dedup signal back to the caller, and have it flow into whether/how pr_public_surface_published is recorded -- e.g. skip recording it (or record it under a distinct outcome/detail) when the actual GitHub-facing PATCH was a confirmed no-op. This fixes the anomaly-counting problem directly without touching whether a pipeline pass runs or what it publishes.
The ops-anomaly detector (
src/review/ops-wire.ts) flags a "review burst / stuck-CI finalize loop" when a PR accumulates >= 6github_app.pr_public_surface_publishedaudit events within 2 hours (findHottestReviewTargetForRepo,src/db/repositories.ts). Confirmed live on 2026-07-16:JSONbored/loopover#6641(6 publishes) andJSONbored/metagraphed#6264(22 publishes).Root cause: an external CI system flapping (queued -> completed -> re-queued...) on the same head SHA causes the finalize pipeline to legitimately re-run and publish each time
ci.hasVisiblePendingreads false.createOrUpdateIssueCommentWithMarker(src/github/comments.ts) already dedupes the actual GitHub PATCH when the rendered comment body is byte-identical -- but that dedup is invisible to the audit/metrics layer, which unconditionally recordspr_public_surface_publishedand pushes topublishedOutputsregardless of whether the GitHub-facing content actually changed (src/queue/processors.ts~8470, ~10573).The existing
#regate-churnno-op guard (processors.ts~9728-9744) does NOT generalize to fix this: it's deliberately scoped topublicSurface: "off"(check-run-only) repos, per its own comment --lastPublishedSurfaceShais documented as "reporting/diagnostic state, not a hard scheduled-sweep skip" because a comment can be stale/partial even when the head marker matches. Blindly extending that guard to comment/label-surface repos (loopover/metagraphed's normal mode) risks silently skipping a genuinely-needed republish.Correct fix, scoped to the metrics layer, not the publish-decision logic: thread
createOrUpdateIssueCommentWithMarker's existing no-op/dedup signal back to the caller, and have it flow into whether/howpr_public_surface_publishedis recorded -- e.g. skip recording it (or record it under a distinct outcome/detail) when the actual GitHub-facing PATCH was a confirmed no-op. This fixes the anomaly-counting problem directly without touching whether a pipeline pass runs or what it publishes.