Repository navigation
fix(OMN-15038): vendor delegation projection drop migration - #2437
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 52 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 (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
| Verdict | Meaning | Blocks merge? |
|---|---|---|
passed |
No critical findings | No |
blocked |
CRITICAL findings found | Yes |
degraded |
All models unavailable (infra) | No (pilot) |
Powered by omniintelligence.review_pairing.cli_review — node-based adversarial review via HandlerLlmCliSubprocess (OMN-8468/OMN-8524)
…bly (#2440) The lab host's operator-maintained checkout under ~/.omnibase/runners/ (synced by deploy-runners.sh's rsync_artifacts, which only runs inside its full/disruptive pipeline) had drifted 19 days behind origin/dev: image_version 5 vs 6, plus 6 more stale SYNC_PATHS entries (config/runner_fleet.yaml, pyproject.toml, uv.lock, Dockerfile, entrypoint.sh, docker-compose.runners.yml). Running containers were correctly at image_version 6 (OMN-15104) -- this was specifically the host-side staged checkout, a distinct artifact. Adds scripts/ci/check_runner_host_artifact_freshness.py: sha256-diffs every deploy-runners.sh SYNC_PATHS entry between a local repo checkout and its rsynced copy on the runner host, fail-closed on any unreadable/missing path. Wires it into deploy-runners.sh's SYNC_PATHS (so it ships to the host) and adds install_host_artifact_freshness_cron (mirrors the existing install_health_cron / install_network_janitor_cron local-cron pattern) so this drift class can no longer sit silent for weeks. Ticket: OMN-15114 (parent OMN-13932; closes a gap OMN-15104 left explicitly unmet in its own acceptance criteria). Local pre-commit SKIP note: onex-check-node-migration-sync (always_run, unrelated to this diff) currently fails against ANY omnibase_infra commit -- dev HEAD 83c2d60 already merged the vendored copy of 0024_drop_unwired_routing_columns.sql (PR #2437, OMN-15038) but its omnimarket source (PR #1883) is still OPEN/CLEAN pending Codex's merge sweep, a landing-order artifact of two coupled cross-repo PRs, not something this ticket can or should fix. Skipped locally with full disclosure; the real CI gate runs unmodified on push and is verified via gh pr checks before this is reported done. Co-authored-by: Jonah Gray <jonah.g.gray@gmail.com>
…g every dev-lane lab pass (#3387) omnimarket#2437 (9d14eecf, merged 2026-09-10T04:17:04Z) added a `ledger_readback` block to the dev lane of omnimarket config/ci_bus_lanes.yaml. scripts/trigger_rebuild_on_merge.py sparse-checks that same file and validates it with extra="forbid". It had not learned the key, so it rejected the whole overlay: lanes.dev.ledger_readback Extra inputs are not permitted That is not a cosmetic red. This publisher is what emits the rebuild-requested event, so while it is broken the deploy agent does not rebuild the .201 dev lane on merge -- which is the automatic lab pass of CLAUDE.md rule 24(a). Every runtime-affecting merge in the window landed on dev with no lab pass behind it, including other lanes' work. Confirmed live on two unrelated branches within two minutes of that merge (omnibase_infra#3379 at 04:18:09Z, the OMN-18108 lane at 04:19:24Z), with the last green trigger run predating it at 02:08:49Z. Reported by the omnigate-projection-degraded-fix lane, which handed over the evidence rather than opening a competing PR. This is my regression: I authored #2437. THE FIX IS TO MODEL THE KEY, NOT TO LOOSEN THE MODEL. The model's own docstring already recorded this class happening twice -- the transport keys under OMN-18012 (run 34160709151) and projection_readback under OMN-18060 -- and states the rule: an unknown key here is indistinguishable from a typo that would route a publisher to a default it never declared. extra="forbid" stays. A test asserts a genuinely unknown lane key is still refused, so the fix cannot later be mistaken for a licence to relax it. The shape class is generalised from ModelCiBusLaneProjectionReadback to ModelCiBusLaneDsnReference and used by both blocks, because this publisher is not a consumer of either and needs nothing from them but their shape. The two remain SEPARATE FIELDS: two legs, two relations, two OMN-16025 links, and the component that does act on them keeps them apart for that reason. Proof, with a negative control: - The live merged overlay from omnimarket@dev now validates: CI_BUS_OVERLAY_LIVE_PATH=<omnimarket@dev:config/ci_bus_lanes.yaml> pytest tests/unit/scripts/test_ci_bus_overlay_live_binding.py -> 6 passed. - The same live overlay against origin/dev's unfixed publisher still refuses on lanes.dev.ledger_readback, so the pass above is the fix and not a fixture that never exercised the path. - 55 passed across the new suite plus the two existing trigger suites. RED first: 2 of 6 new cases failed before the change. Structural residual, stated rather than left implied: nothing in omnimarket fails when a new overlay key is added there. The publisher only discovers it after that PR has merged, on someone else's unrelated omnibase_infra PR. Three occurrences of one shape is a structural gap, not three mistakes. A cross-repo parity gate would move the failure to the PR that causes it; it is filed separately rather than bolted on here.
Refs OMN-15038
Summary
Verification
No live deploy performed.
Evidence-Ticket: OMN-15038
Evidence-Source: OCC#4800
Evidence-Commit: 53e14f927a6ef80910fabeeabe58576b4cb21087
Omnimarket-Source-Ref: jonah/omn-15038-drop-unwired-routing-columns