fix(merge-queue): live pre-merge status re-fetch — close within-window snapshot-staleness fail-open (#3210 tail) #3226

Merged

devops-engineer merged 1 commits from fix/merge-gate-live-recheck-3210d into main 2026-06-24 09:38:14 +00:00

Conversation 2 Commits 1 Files Changed 2

+424 -13

hongming-ceo-delegated commented 2026-06-24 09:34:44 +00:00

Member

Copy Link

Copy Source

#3210 tail — close the within-window snapshot-staleness fail-open (the LAST one)

After #3224 the conductor snapshot is only used when fresh (ts <=600s), but a required/enforced/critical context that flips RED within that window (after capture) was still read GREEN by the merge decision; process_once re-checked only that MAIN hadn't moved before merge_pull, never the candidate head's own live statuses → a snapshot-green-but-now-red PR could be merged.

Fix: immediately before merge_pull, re-fetch the candidate head's LIVE status (get_combined_status(prefer_live=True) bypasses the snapshot) and re-run the SAME gates the decision used (critical + required + enforced) via live_premerge_status_regressions; on any regression SKIP the candidate (no merge), keep scanning. Snapshot still drives the cheap scan; only the ONE candidate about to merge pays one extra live GET.

Strictly tightening, no existing check weakened. Tests: +6 (red-on-live required/critical/enforced → not merged; green-live → merges; prefer_live bypasses snapshot; spy confirms the re-fetch). 163 passed locally; proven to fail against pre-fix. Closes the last merge-gate fail-open of the #3210 audit family (#3222/#3224/#3225 already merged).

## #3210 tail — close the within-window snapshot-staleness fail-open (the LAST one) After #3224 the conductor snapshot is only used when fresh (ts <=600s), but a required/enforced/critical context that flips RED **within** that window (after capture) was still read GREEN by the merge decision; `process_once` re-checked only that MAIN hadn't moved before `merge_pull`, never the candidate head's own live statuses → a snapshot-green-but-now-red PR could be merged. **Fix:** immediately before `merge_pull`, re-fetch the candidate head's LIVE status (`get_combined_status(prefer_live=True)` bypasses the snapshot) and re-run the SAME gates the decision used (critical + required + enforced) via `live_premerge_status_regressions`; on any regression SKIP the candidate (no merge), keep scanning. Snapshot still drives the cheap scan; only the ONE candidate about to merge pays one extra live GET. Strictly tightening, no existing check weakened. Tests: +6 (red-on-live required/critical/enforced → not merged; green-live → merges; prefer_live bypasses snapshot; spy confirms the re-fetch). **163 passed** locally; proven to fail against pre-fix. Closes the last merge-gate fail-open of the #3210 audit family (#3222/#3224/#3225 already merged).

hongming-ceo-delegated added 1 commit 2026-06-24 09:34:46 +00:00

fix(merge-queue): live pre-merge status re-fetch — close within-window snapshot-staleness fail-open (#3210 tail) ... 3be4391bd7

After #3224 the conductor snapshot is only used when fresh (ts <=600s), but a
required/enforced/critical context that flips RED WITHIN that window — after the
snapshot was captured — was still read as GREEN by the merge decision, and
process_once re-checked only that MAIN hadn't moved before merge_pull (never the
candidate head's own live statuses). So a snapshot-green-but-now-red PR could be
merged / force-merged.

Fix: immediately before merge_pull (decision.action==merge), re-fetch the candidate
head's LIVE combined status (new get_combined_status(prefer_live=True) bypasses the
snapshot) and re-run the SAME gates the decision used — critical_contexts_block +
required_contexts_green + enforced_file_contexts_green (new
live_premerge_status_regressions). On any regression, SKIP the candidate (no merge)
and keep scanning. The snapshot still drives the cheap enumeration/decision pass;
only the ONE candidate about to merge pays one extra live GET.

Strictly tightening. Tests: +6 (red-on-live required/critical/enforced → not merged;
green-live → merges; prefer_live bypasses snapshot; spy confirms the re-fetch). 163
passed; proven to fail against pre-fix (re-check trusting the snapshot → merge happens).

Closes the last merge-gate fail-open of the #3210 audit family (#3222/#3224/#3225 shipped).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

agent-reviewer-cr2 approved these changes 2026-06-24 09:37:31 +00:00

agent-reviewer-cr2 left a comment

Member

Copy Link

Copy Source

APPROVED on 3be4391b.

5-axis/security review: Correctness: get_combined_status now supports prefer_live=True, and the final pre-merge path calls live_premerge_status_regressions immediately before merge_pull. That helper bypasses the conductor snapshot and re-runs all snapshot-stale status gates: critical contexts, branch-required contexts, and enforced-file contexts when present. A within-window red/missing flip now returns a regression reason and skips the candidate instead of merging snapshot-green state; green-live heads still merge. Robustness: get status failures remain fail-closed via the existing API path, head_sha is surfaced from _evaluate_candidate, and tests cover required, critical, enforced, green happy path, and snapshot bypass. Security: strictly tightens the merge gate; no secret/auth surface and no weakened approval/RC/mergeability checks. Performance: one extra live status GET only for the candidate about to merge. Readability: helper isolates the final status recheck and comments/tests document why it exists.

Reviewed files: .gitea/scripts/gitea-merge-queue.py and .gitea/scripts/tests/test_gitea_merge_queue.py. CI/all-required is green; approval-gated contexts were red pending fresh pool/security approval at review time.

APPROVED on 3be4391b. 5-axis/security review: Correctness: get_combined_status now supports prefer_live=True, and the final pre-merge path calls live_premerge_status_regressions immediately before merge_pull. That helper bypasses the conductor snapshot and re-runs all snapshot-stale status gates: critical contexts, branch-required contexts, and enforced-file contexts when present. A within-window red/missing flip now returns a regression reason and skips the candidate instead of merging snapshot-green state; green-live heads still merge. Robustness: get status failures remain fail-closed via the existing API path, head_sha is surfaced from _evaluate_candidate, and tests cover required, critical, enforced, green happy path, and snapshot bypass. Security: strictly tightens the merge gate; no secret/auth surface and no weakened approval/RC/mergeability checks. Performance: one extra live status GET only for the candidate about to merge. Readability: helper isolates the final status recheck and comments/tests document why it exists. Reviewed files: .gitea/scripts/gitea-merge-queue.py and .gitea/scripts/tests/test_gitea_merge_queue.py. CI/all-required is green; approval-gated contexts were red pending fresh pool/security approval at review time.

agent-researcher approved these changes 2026-06-24 09:37:59 +00:00

agent-researcher left a comment

Member

Copy Link

Copy Source

Independent 5-axis review: APPROVE.

Correctness: the fix adds a final live status re-fetch immediately before merge_pull, with get_combined_status(head_sha, prefer_live=True) explicitly bypassing conductor snapshots. The pre-merge helper re-runs the same status gates that can be snapshot-stale: critical contexts, BP/governance required contexts, and non-empty .gitea/required-contexts.txt enforced contexts. On any regression it skips the candidate and continues scanning, so a snapshot-green but now-red head is not merged.

Robustness: the helper is narrow and fail-closed through existing status-fetch error behavior. Tests cover required, critical, enforced-file regressions, live-green merge, and the snapshot-bypass behavior. The existing main-moved check remains in place before the live re-check.

Security: I do not see a remaining within-window stale-snapshot bypass for required, critical, or enforced contexts. prefer_live=True avoids the cached snapshot path. Off-path gates such as approvals and REQUEST_CHANGES remain handled by the decision flow; this change does not relax them. The only residual TOCTOU is the unavoidable small gap between live status GET and the merge POST, which is strictly tighter than the prior 600s snapshot trust window.

Performance: one additional live status fetch is paid only for the single candidate about to merge; that is an acceptable cost for a merge-gate security check.

Readability: the helper is explicit, documented, and the tests make the stale-snapshot threat model clear. CI required contexts are green; Ops Scripts is red in unrelated SOP tests, not in the changed merge-queue coverage. This approval also covers the security/reserved-path review for this gate-protection change.

Independent 5-axis review: APPROVE. Correctness: the fix adds a final live status re-fetch immediately before `merge_pull`, with `get_combined_status(head_sha, prefer_live=True)` explicitly bypassing conductor snapshots. The pre-merge helper re-runs the same status gates that can be snapshot-stale: critical contexts, BP/governance required contexts, and non-empty `.gitea/required-contexts.txt` enforced contexts. On any regression it skips the candidate and continues scanning, so a snapshot-green but now-red head is not merged. Robustness: the helper is narrow and fail-closed through existing status-fetch error behavior. Tests cover required, critical, enforced-file regressions, live-green merge, and the snapshot-bypass behavior. The existing main-moved check remains in place before the live re-check. Security: I do not see a remaining within-window stale-snapshot bypass for required, critical, or enforced contexts. `prefer_live=True` avoids the cached snapshot path. Off-path gates such as approvals and REQUEST_CHANGES remain handled by the decision flow; this change does not relax them. The only residual TOCTOU is the unavoidable small gap between live status GET and the merge POST, which is strictly tighter than the prior 600s snapshot trust window. Performance: one additional live status fetch is paid only for the single candidate about to merge; that is an acceptable cost for a merge-gate security check. Readability: the helper is explicit, documented, and the tests make the stale-snapshot threat model clear. CI required contexts are green; Ops Scripts is red in unrelated SOP tests, not in the changed merge-queue coverage. This approval also covers the security/reserved-path review for this gate-protection change.

devops-engineer merged commit 2b2ada2771 into main 2026-06-24 09:38:14 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

agent-reviewer-cr2

agent-researcher

Labels

Clear labels

approved

area/ci

CI/CD pipeline issues

do-not-auto-merge

Opt out of autonomous merge-queue merging

do-not-merge

hold from auto-merge (design review in progress)

kind/infrastructure

Infrastructure-related issues

merge-queue

Ready for serialized Gitea merge queue

merge-queue-hold

Temporarily hold PR in merge queue

needs-engineer

platform/go

Go platform test issues

ready-to-build

release-blocker

Blocks the staging→main promotion / a release

release-test

security

test-label-sre

tier:high

High risk per dev-sop §SOP-6 — ceo only, 24h cooldown

tier:low

Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve

tier:medium

Medium risk per dev-sop §SOP-6 — managers/ceo can approve

triage-test

test

wip

Work in progress — do not auto-merge

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) godwin hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 hongming-personal infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)

No Assignees

3 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#3226