fix(agent-mention): enforce repository_dispatch property cap on current main - #911
fix(agent-mention): enforce repository_dispatch property cap on current main#911seonghobae wants to merge 4 commits into
Conversation
|
Warning Review limit reached
Next review available in: 36 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review Please perform a fresh semantic source review of unchanged exact head |
|
|
|
@opencode-agent review Evaluate exact current head |
|
Superseded by #840 on the same protected-main base. #840 resolves the identical GitHub |
…already exist and are structurally inert Traced the actual code: a real circuit breaker (_record_failure/ _circuit_open, wired into _failover_candidates) and a real concurrent racing path (_equivalent_race_members) both already exist in contextual-orchestrator. Neither can help the observed stall: the circuit breaker is in-memory per-process state, but the review sidecar boots a fresh process per CI job and makes exactly one request before exiting, so there's never a second request to benefit from a circuit that only opens after 3 accumulated failures. #911's routing-observation data has the identical structural problem -- also in-memory, also reset per process -- so the skip-fast design this entry originally proposed would have been just as inert, not a fix. Racing is inert for a different reason: it requires candidates to share a group_name and a declared endpoint_equivalence contract proving they're redundant replicas of the same model; the free-tier pool has neither -- its members are different models entirely, so racing them is a real speed-vs-quality product tradeoff, not a mechanical extension. Splits the revised direction into two genuinely different fixes (persist state across the ephemeral process boundary, vs. extend racing to non-equivalent candidates with an explicit tradeoff decision) instead of the two originally proposed, neither of which would have worked.
…911 contextual-orchestrator#911 (open, unmerged) already builds real, tested cross-process persistence infrastructure (routing_observation_ store.py, SQLite-backed, time-windowed) -- exactly what item 4's "persist state across the ephemeral process boundary" direction calls for. But it wires that store into the ranking ledger (_group_router), which per this entry's own earlier finding is never consulted for the free-tier pool's ungrouped candidates anyway. The mechanism that *is* consulted regardless of grouping -- the circuit breaker (self._circuit) -- isn't touched by #911 at all. Flags the concrete next step (route the circuit breaker through the same already-built store) without implementing it, since #911 itself is still unmerged and could change shape before landing.
Purpose
Replace stale/diverged #910 with the same root-cause repair on current protected-main source. GitHub repository dispatch accepts at most 10 top-level
client_payloadproperties. The protected-main OpenCode mention route carried 14 on the router→wrapper hop, so an authorized mention could be rejected before the trusted wrapper ran.Exact current identity
main;6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba;4e6ecf5c7e0dc88db8f75b8b1faaf9beeb6e1d9b;Root-cause contract
The durable invocation claim still binds repository, PR, exact head/base, base branch, source comment, requesting actor, requested agent, and the five immutable review-only controls:
trigger_reviews=true;review_dispatch_limit="1";enable_auto_merge=false;update_branches=false;merge_mode="disabled".Transport is narrower than authority binding:
No mutable caller-selected review/merge controls, secret, reviewer authority, or branch-write capability is added.
TDD evidence
Initial RED head
02a86f342ff779145ae7d023c7f096ede4148b04added the permanent property-cap contract. Agent Mention Router Quality CI reproduced the defect against protected-main behavior: OpenCode initial payload had five extra behavior properties beyond the allowed identity set.After the current-main router/wrapper repair, exact head
f0bb2b75283fe56f3d5cce1e82885fca7b0a4996exposed one stale pre-existing test that still expected the old 14-property transport. That was a test-contract mismatch, not a production rollback requirement. The current head updates that expectation while separately asserting the full canonical claim still contains all five fixed review-only controls.At exact current head
4e6ecf5c7e0dc88db8f75b8b1faaf9beeb6e1d9b, Agent Mention Router Quality CI and all eight security/supply-chain workflows completed successfully before the Ready transition. That evidence remains exact-head history, while the newly queued Ready-cycle runs are not passing until terminal-success.Supersession / acceptance
#910 is closed unmerged and remains preserved as stale lineage. Keep this successor unmerged until the Ready-cycle exact-head gates are terminal-success, current automated source review has no valid unresolved finding, a qualifying independent non-author formal approval exists, live-base compatibility is independently resolved, and branch protection authorizes integration.
After protected integration, exercise an authorized OpenCode mention through the real router→wrapper→scheduler path and require a durable exact-name invocation artifact plus review-only downstream behavior. Predecessor or local-only evidence does not close that operational scenario.