Repository navigation
fix(OMN-15411): SIGPIPE-safe OMN-15172 gate checks - #5523
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 15 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
65c1870 to
b57f08a
Compare
b57f08a to
3c02b44
Compare
…rsession (#5543) * fix(OMN-15430): literal-pin the deploy-scope DoD via append-only supersession contracts/OMN-15430.yaml dod-deploy-assessment carried bare runner-substituted PR_NUMBER/REPO placeholder tokens under an id embedding no pr-<N> segment. The id does not match node_dod_verify _EVIDENCE_ID_BINDING_RE, so _repo_and_pr_from_evidence_id yields no binding, _lookup_pr_for_ticket has no repo to scope a PR search to, and the item hard-REDs at _resolve_command_placeholders with PR_LOOKUP_FAILED before the command is ever shelled out. Reproduced on three independent dod_verify runs; it is the single red blocking the OMN-15430 flip. Supersedes that entry (append-only, supersedes_dod_evidence idiom per OMN-14875/OMN-15382, precedent OCC#5496/#5523) with dod-deploy-assessment-pr-1958-literal-pin: same deploy-scope path regex, literally pinned to OmniNode-ai/omnimarket#1958 with a literal --repo and no runner-substituted token, SIGPIPE-safe (producer drained into a shell variable before any grep reads), shlex-parseable, fail-closed on producer failure. Proven by execution: GREEN 3/3 under bash -o pipefail -c, 1/1 under sh -c; RED under three mutations (absent anchor path, repointed at OCC#5516, nonexistent repo). * evidence(OMN-15430): PASS receipts + self-bind for the literal-pinned deploy DoD Adds the OCC self-bind entry occ-self-bind-pr-5543 (the occ-preflight eligibility gate requires a PASS receipt binding OMN-15430 to this PR) and executed-probe PASS receipts for it and for dod-deploy-assessment-pr-1958-literal-pin. Both receipts were minted by executing the declared check_value live on the gate host under bash -o pipefail -c, not hand-authored: exit 0 for both. contract_entry_sha256 bindings verified against compute_contract_entry_sha256() post-yamlfmt (unchanged across the append, per OMN-13888/OMN-14411).
#6595's own Contract Corpus Ratchets (OMN-15411) check failed the census baseline: both new dod_evidence check_values matched the measured SIGPIPE-fragile shape. dod-OmniNode-ai-omnibase_infra-pr-2768: `... | base64 -d | grep -q ...` -- the "base64-decoded file body" producer, measured 141,0,141,0,141 across 5 runs against the corpus' own real inputs. dod-OmniNode-ai-omnibase_infra-pr-2768-ci: `--jq '[.[].filename]' | grep -qxF ...` -- the "iterating jq projection" producer (unbounded output by construction, `.[]` in the jq expression). `grep -q`/`grep -qxF` exit at the first match and close stdin; if the upstream producer still has bytes to write it is killed by SIGPIPE (exit 141), which `bash -o pipefail` propagates as a false RED on genuinely-passing evidence. Rewritten per the documented repair idiom (occ#5496/#5523 precedent, fetched and matched field-for-field): buffer the producer's full output into a shell variable first, so it runs to completion before anything reads from it, then pipe a printf of that variable into grep -qF. Re-verified both probes live against #2768's real head -- same PASS result, same RED-control failure against wrong input. Verified against the actual gates, not inferred: - onex_change_control.validation.evidence_admissibility.classify_evidence -> both items still ADMISSIBLE (gh-api + grep in command position unaffected by the buffering). - scripts/lint_contract_check_values._sigpipe_producer_label -> None for all three dod_evidence items (Rule E clean). - uv run pytest tests/unit/scripts/test_lint_contract_check_values_corpus_baseline.py -> 17/17 passed locally (was 3 failed before this fix). - validator_occ_append_only --ticket-id OMN-16114 -> ok:true (all four files still diff as pure 'A' against the origin/dev merge-base). - validator_occ_merge_eligibility (companion's own in-tree binding, both commits cited) -> eligible:true, unchanged. contract_entry_sha256 recomputed for the two edited items via the canonical hashers; occ-self-bind-pr-6595's own per-entry hash is byte-identical (unaffected, confirming append-immunity). Evidence-Ticket: OMN-16114
#6595) * evidence(OMN-16114): author OCC companion for OmniNode-ai/omnibase_infra#2768 The occ-autobind born-path event for this PR was swallowed at the consumer twice in a row -- not a replay-tooling failure, a delivery-guarantee gap. Confirmed forensically via live workflow logs rather than assumed: 1. Original PR-open trigger (pull_request event, run 32008569724, 08:03:41Z, head f18eee68f0933eb3206f909c4d8079e952647bb3): produced no companion. 2. Manual workflow_dispatch replay #1 (run 32010077750, job 95327597955): the publish step ran clean -- "Published onex.cmd.omnimarket.occ-autobind.v1 event_id=9e01122d-9253-40b1-83c5-ef2583280482" at 08:25:14Z, to the dev-lane broker (omninode-pc.tail75df5e.ts.net:19092). No companion appeared after 74+ minutes. 3. Manual workflow_dispatch replay #2, fired from this lane (run 32016316098, job 95346440127): also published clean -- "Published onex.cmd.omnimarket.occ-autobind.v1 event_id=e3defa43-ff9a-4c67-9b7c-72fe9e7bd77c" at 09:44:30Z (the job's overall conclusion shows "cancelled", but that fired AFTER the publish step completed and logged success -- the cancellation did not touch the already-published event). No companion after 5+ minutes at authoring time. Two independent, successfully-published events for the same PR/ticket with zero consumption is new evidence for the delivery-guarantee defect thread -- the failure is at the consumer/effect-handler side, not the publisher. Hand-authored on the occ#6573/OMN-10221 and OMN-16112/occ#6589 manual-companion precedent per controller authorization. Learned from the occ#6589 lane (same session): bare `gh pr view --json ...` is the OMN-15309-inadmissible "PR-existence probe" anti-pattern, so both dod_evidence checks here are built admissible from the start -- content-bound, RED-verified probes, not existence probes: dod-OmniNode-ai-omnibase_infra-pr-2768: gh api .../contents/docker/runners/runner-job-started.sh?ref=<sha> reads the actual file content at #2768's head and asserts the new shared rewrite-flush function (_c2_rewrite_flush) is present. RED-verified: zero matches at the PR's base ref. dod-OmniNode-ai-omnibase_infra-pr-2768-ci: gh api .../pulls/2768/files reads the actual diff (admitted per the module's own guidance) and asserts the exact two-file change set. Locally verified via onex_change_control.validation.evidence_admissibility .classify_evidence directly: both items -> ADMISSIBLE. Local validator_occ_merge_eligibility run against #2768's real title/branch/ commit-sha with this commit's on-disk contract+receipts returns eligible:true. STILL REQUIRED before this can pass occ-preflight on its own PR: the occ-self-bind-pr-<N> entry + receipt, which cannot exist until the PR number does -- same two-commit shape as the merged #6573/#903/#6589 companions. Evidence-Ticket: OMN-16114 * evidence(OMN-16114): occ-self-bind-pr-6595 Appends the mandatory self-bind evidence item for OCC companion PR #6595, per the merged #903/#6492/#6573/#6589 pattern (OMN-14650). This item cannot exist before the PR number does, so it lands as a second commit after opening #6595. Local verification, all green: - validator_occ_append_only --ticket-id OMN-16114 (base = merge-base with origin/dev) -> ok:true. - validator_occ_merge_eligibility run twice: once as onex_change_control's own in-tree PR (#6595, its own title/branch/commit) -> eligible:true, and once simulating omnibase_infra#2768's real body with a live 'Evidence-Source: OCC#6595' line appended -> eligible:true. - check-receipt-honesty, check-contract-substance-floor, check-contract-shape-v1, check-dod-authoring-hygiene, check-receipt-hardening all Passed locally. Evidence-Ticket: OMN-16114 * fix(OMN-16114): SIGPIPE-safe the two content-bound probes (Rule E) #6595's own Contract Corpus Ratchets (OMN-15411) check failed the census baseline: both new dod_evidence check_values matched the measured SIGPIPE-fragile shape. dod-OmniNode-ai-omnibase_infra-pr-2768: `... | base64 -d | grep -q ...` -- the "base64-decoded file body" producer, measured 141,0,141,0,141 across 5 runs against the corpus' own real inputs. dod-OmniNode-ai-omnibase_infra-pr-2768-ci: `--jq '[.[].filename]' | grep -qxF ...` -- the "iterating jq projection" producer (unbounded output by construction, `.[]` in the jq expression). `grep -q`/`grep -qxF` exit at the first match and close stdin; if the upstream producer still has bytes to write it is killed by SIGPIPE (exit 141), which `bash -o pipefail` propagates as a false RED on genuinely-passing evidence. Rewritten per the documented repair idiom (occ#5496/#5523 precedent, fetched and matched field-for-field): buffer the producer's full output into a shell variable first, so it runs to completion before anything reads from it, then pipe a printf of that variable into grep -qF. Re-verified both probes live against #2768's real head -- same PASS result, same RED-control failure against wrong input. Verified against the actual gates, not inferred: - onex_change_control.validation.evidence_admissibility.classify_evidence -> both items still ADMISSIBLE (gh-api + grep in command position unaffected by the buffering). - scripts/lint_contract_check_values._sigpipe_producer_label -> None for all three dod_evidence items (Rule E clean). - uv run pytest tests/unit/scripts/test_lint_contract_check_values_corpus_baseline.py -> 17/17 passed locally (was 3 failed before this fix). - validator_occ_append_only --ticket-id OMN-16114 -> ok:true (all four files still diff as pure 'A' against the origin/dev merge-base). - validator_occ_merge_eligibility (companion's own in-tree binding, both commits cited) -> eligible:true, unchanged. contract_entry_sha256 recomputed for the two edited items via the canonical hashers; occ-self-bind-pr-6595's own per-entry hash is byte-identical (unaffected, confirming append-immunity). Evidence-Ticket: OMN-16114
#6612) * evidence(OMN-16115): hand-authored OCC companion for OmniNode-ai/omnibase_infra#2766 The occ-autobind born-path event was swallowed at the consumer for this PR. The original PR-open trigger (job 95292560731, run 31997821498, 05:26:34Z) published event_id 92e8286a-2ecf-43fa-9bd4-6605dee28bd3 -- but BEFORE the PR was retitled to carry the OMN-16115 ticket token, so that event never named a ticket at all. One authorized workflow_dispatch replay after the retitle (event_id 871d0f42-f3e0-4437-87c6-4153f5ca89f4, 12:54:48Z, confirmed published to onex.cmd.omnimarket.occ-autobind.v1 on the dev-lane broker) produced no companion after 30+ minutes. Hand-authored per controller authorization, on the OMN-16112/occ#6589 and OMN-16114/occ#6595 manual-companion precedent. Two content-bound, admissible-from-the-start probes (learned from the OMN-16112/occ#6589 lane's Contract Compliance Check BLOCK on bare `gh pr view` evidence): dod-OmniNode-ai-omnibase_infra-pr-2766 confirms `async def run_worker_loop(` landed in scripts/edge_delegation_worker/worker_cycle.py at #2766's head (ebd4c098fef2eea1fa9f2df6217429436e627192), RED-verified against the PR's base ref (a5945502fa170805c2fce9247c8be58eac657374, where the file 404s entirely). dod-OmniNode-ai-omnibase_infra-pr-2766-ci confirms the PR's actual diff file list via pulls/2766/files, RED-verified against a fabricated file list. Both SIGPIPE-safe per OMN-15411 Rule E (producer output buffered into a shell variable before the grep -q consumer reads it, occ#5496/#5523 repair idiom) and both re-executed directly (exit 0) against the final staged receipt bytes. contract_sha256/ contract_entry_sha256 computed via the canonical omnibase_core.validation.validator_receipt_gate hashers. * evidence(OMN-16115): self-bind OCC companion PR #6612 OCC companion PR #6612 -- self-bind for OMN-16115, mirroring the occ-self-bind-pr-6595 shape. validator_occ_merge_eligibility requires at least one PASS receipt on the cited ticket to bind to the OCC PR carrying the evidence, otherwise the companion is ineligible with reason pr_ticket_mismatch. contract_sha256 recomputed for all three receipts against the contract bytes with the self-bind entry added; contract_entry_sha256 for the two pre-existing items is unchanged (per-entry hash is position-independent, OMN-13888).
…#6726) * fix(OMN-15461): receipt hardening gate validates commit_sha existence Adds a seventh invariant (COMMIT_SHA_EXISTS) to check_receipt_hardening.py's shared _receipt_binding_violations core: a receipt's commit_sha must resolve to a real, remote-reachable commit, not merely a locally-existing git object. Closes two live incidents, different in kind, same mechanism: - Local-worktree-only commits from the .200 patch-transfer workflow (13+ confirmed instances, OCC#5496/#5523/#5541, OMN-15413 merge-base receipts). - A prefix-plausible fabricated SHA (OCC#6725, 2026-08-19): 10-hex real prefix + invented remainder, which no format/regex check can catch. Resolver: local git branch -r --contains (fast path, no network) -> GitHub API against onex_change_control (covers shallow/incomplete checkouts) -> GitHub API against a repos/<owner>/<repo>/ hint embedded in probe text, for receipts documenting a check against a product repo (commit_sha itself carries no repo attribution). Unresolvable by all three is a hard FAIL. Deliberately cutoff-gated (OMN_15461_CUTOFF, like OMN_15710_CUTOFF before it) rather than a full-corpus shrink-only baseline — a corpus-wide sweep would require a gh api call per historical commit_sha across ~14,000 receipts. The pre-existing corpus (including the 13+ known-bad SHAs already named in the ticket) remains correctable via the same append-only supersession path every other rule in this file already honors. 12 new tests: RED for local-only/never-pushed, prefix-plausible fabrication (exact OCC#6725 SHA pair), and nonexistent cross-repo SHA; GREEN for local and cross-repo-hint resolution; cutoff exemption; monkeypatch wiring through check_receipt_file; supersession-excuse path. Live-verified (not just mocked) against the real production resolver: a real pushed HEAD commit resolves via both local git and gh api; the OCC#6725 fabricated SHA and a never-pushed placeholder both correctly fail both paths. Evidence-Ticket: OMN-15461 * evidence(OMN-15461): contract for commit_sha existence gate PR #6726 Evidence-Ticket: OMN-15461 * evidence(OMN-15461): self-bind receipts for commit_sha existence gate PR #6726 Evidence-Ticket: OMN-15461 * fix(OMN-15461): widen repo-hint extraction, fix false positives found in bounded audit Live bounded audit (1052 receipts added to OCC in the last 7 days, 896 unique commit_sha values) against the just-shipped PR #6726 resolver found 76 apparent failures. Investigating each before reporting found the initial _REPO_HINT_RE (URL-path form only, "repos/<owner>/<repo>/") missed the corpus's actual dominant convention: the occ-evidence-source-autobind verifier's "gh pr view <n> --repo <owner>/<repo>" CLI-flag form, plus its generated evidence_item_id shape ("dod-OmniNode-ai-<repo>-pr-<n>"). All 76 were genuine receipts my own narrower regex would have false-positived on the first future PR past the cutoff. Widens _REPO_HINT_RE to also match --repo[= ]<owner>/<repo>, and adds an evidence_item_id fallback for cohort-sibling receipts (e.g. dod-occ-evidence-admissibility-validator) whose own probe text carries no repo-identifying text but whose id follows the autobind convention. Re-ran the audit end-to-end through the ACTUAL production _commit_sha_resolves function (not the ad hoc per-hint checks used to investigate the false positives): 896 unique receipts, exactly 2 genuine unresolvable commit_sha values, reported in the PR body — not mass-edited, per the audit's bounded scope. 4 new regression tests for the widened hint extraction. Evidence-Ticket: OMN-15461 * fix(OMN-15461): restrict repo-hint fallback to a known repo allowlist Independent adversarial verification (2026-08-19) found a real fail-open bug in the cross-repo hint fallback: _REPO_HINT_RE matched ANY "<owner>/ <repo>" string appearing in check_value/probe_command/actual_output with no restriction, so a fabricated commit_sha paired with probe text that happened to mention an unrelated real repo (demonstrated live with torvalds/linux) would resolve as "real" -- the exact fabrication-bypass class this gate exists to close, reopened through the hint fallback added earlier today to fix the false-positive audit findings. Adds _KNOWN_REPO_HINTS, an explicit allowlist mirroring CLAUDE.md's Repository Registry plus the personal repos observed live in the corpus (steel_onslaught, omnicursor). _repo_hint now scans every candidate match in a field (not just the first) and only returns one that is a member of the allowlist; an unrecognized repo is treated as no hint, not trusted. Re-ran the full 896-receipt bounded audit against the fixed resolver: still exactly the same 2 genuine hits, zero false positives reintroduced. 5 new adversarial regression tests, including an end-to-end case proving the fabricated-SHA-plus-unrelated-real-repo bypass is now closed and that remote_exists is never even called against the unrecognized repo. Evidence-Ticket: OMN-15461
Fixes a reproducible SIGPIPE false-RED (exit 141) on three of OMN-15172's content-probe dod_evidence checks:
Root cause: each check_value pipes
gh api ... --jq .content | base64 -d | grep -q '<marker>'.grep -qcloses stdin at the first match, killing the upstream
base64 -d(and transitivelygh api's curl) withSIGPIPE once the pipe drains. Under
pipefail(the dod_verify runner's shell mode) that SIGPIPE exit(128+13=141) propagates as the pipeline's exit code even though the substantive grep matched — a
reproducible false RED inside the runner, while the same command exits 0 run directly (no pipefail).
Content at the pinned refs is verified genuinely present (mutation-proven falsifiable).
Fix follows the exact idiom proven and merged on OMN-15170 (
dod-steel220-omn15170-sigpipe-safe):append-only supersede entries per
evidence_artifact: supersedes_dod_evidence:<id>, replacing theshort-circuiting
grep -qpipeline with a fail-closed buffered read (body="$(... | base64 -d)"thengrep -qFon the buffered variable). All three new checks were executed 5x each (all green), and eachwas independently proven to go RED under a mutated/absent marker string, confirming falsifiability is
preserved. Matching receipts under
drift/dod_receipts/OMN-15172/carrycontract_entry_sha256computedvia
compute_contract_entry_sha256;scripts/validation/check_receipt_hardening.pyandscripts/lint_contract_check_values.pyboth pass.Cites OMN-15172 (the contract being repaired) and OMN-15411 (this corpus-instance ticket, which also
tracks the separate repo-wide
| grep -qsweep — not done in this PR).Evidence-Ticket: OMN-15172
Evidence-Ticket: OMN-15411
Evidence-Source: OCC#5524