Problem
The panel's "Re-run LoopOver review" checkbox — the one escape hatch a maintainer has when a PR's review looks wrong or stale — is unreliable end-to-end, with zero feedback in every failure mode. Two distinct defects observed live on #8972, 2026-07-26:
(a) Clicks can be silently lost. Three checkbox activations produced no trace whatsoever — no pr_panel_retriggered, no pr_panel_retrigger_skipped, no webhook job: two UI clicks (~14:57–15:03Z) and one API-driven comment edit (15:26:21Z, verified live on the comment as - [x], still unprocessed 10+ minutes later). One click (15:15:02Z) processed normally, so the subscription/handler works in general. Whether the deliveries were dropped GitHub-side or at ingress is undetermined — nothing on the receiving side logs a delivery that never became a job. The checkbox stays visibly ticked, nothing happens, and the maintainer concludes ORB is ignoring them.
(b) A processed force re-run can still silently skip the AI review. The 15:15:02Z retrigger ran inline with forceAiReview: true (no defer event, so the immediate-readiness path was taken), completed in ~10s, and republished the same stale placeholder. The audit trail contains none of the events the AI dispatch must emit on every branch: no ai_review_force_bypass, no ai_review_cache_miss/hit, no ai_review_auto_review_skipped, no ai_review_public_summary_missing, no frozen-reuse. Some condition gated aiReviewWillRun off without leaving any record — on a pass whose entire purpose was "spend a fresh review".
Fix
- Receipt feedback: processing a retrigger must visibly acknowledge it (untick the checkbox / add a reaction / bump the panel timestamp) at receipt time, and a delivery that never arrives should be detectable — e.g. a periodic sweep that notices a panel comment whose rerun checkbox is ticked but has no matching
pr_panel_retriggered within N minutes, and treats the ticked box itself as the intent (idempotent recovery, no webhook dependency).
- Exhaustive skip auditing: every conjunct that can make
aiReviewWillRun false must emit an audit event naming itself (several already do; the silent ones must be found and covered). A forced pass that ends with no fresh review and no explanation should be structurally impossible.
- Root-cause (b) with the new auditing and fix it.
Acceptance
- A ticked rerun checkbox always results in either a fresh review or an explicit, named skip event within one sweep interval — never silence.
- Grepping the audit trail for any forced pass shows exactly one of:
force_bypass+review events, or a named skip reason.
Related: #8972 (evidence), the orphaned-lock and sticky-label sibling issues (what the lost clicks collided with).
Problem
The panel's "Re-run LoopOver review" checkbox — the one escape hatch a maintainer has when a PR's review looks wrong or stale — is unreliable end-to-end, with zero feedback in every failure mode. Two distinct defects observed live on #8972, 2026-07-26:
(a) Clicks can be silently lost. Three checkbox activations produced no trace whatsoever — no
pr_panel_retriggered, nopr_panel_retrigger_skipped, no webhook job: two UI clicks (~14:57–15:03Z) and one API-driven comment edit (15:26:21Z, verified live on the comment as- [x], still unprocessed 10+ minutes later). One click (15:15:02Z) processed normally, so the subscription/handler works in general. Whether the deliveries were dropped GitHub-side or at ingress is undetermined — nothing on the receiving side logs a delivery that never became a job. The checkbox stays visibly ticked, nothing happens, and the maintainer concludes ORB is ignoring them.(b) A processed force re-run can still silently skip the AI review. The 15:15:02Z retrigger ran inline with
forceAiReview: true(no defer event, so the immediate-readiness path was taken), completed in ~10s, and republished the same stale placeholder. The audit trail contains none of the events the AI dispatch must emit on every branch: noai_review_force_bypass, noai_review_cache_miss/hit, noai_review_auto_review_skipped, noai_review_public_summary_missing, no frozen-reuse. Some condition gatedaiReviewWillRunoff without leaving any record — on a pass whose entire purpose was "spend a fresh review".Fix
pr_panel_retriggeredwithin N minutes, and treats the ticked box itself as the intent (idempotent recovery, no webhook dependency).aiReviewWillRunfalse must emit an audit event naming itself (several already do; the silent ones must be found and covered). A forced pass that ends with no fresh review and no explanation should be structurally impossible.Acceptance
force_bypass+review events, or a named skip reason.Related: #8972 (evidence), the orphaned-lock and sticky-label sibling issues (what the lost clicks collided with).