{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"circuit_breaker__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"circuit_breaker__computer_science__P1","proposal_index":1,"version":0,"title":"Retry-Storm Breaker for Automated Dependency-Update Merge Queues","problem":"Automated dependency-update bots submit pull requests, rebases, and reruns to a shared CI merge queue. When runner capacity saturates, timeouts and superseded builds cause bots to issue additional refreshes and retries. Those arrivals consume more capacity, invalidate work already underway, and couple one overloaded automation stream to the validation of unrelated changes.","actors":["Automated dependency-update bots","CI merge-queue controller","CI runners","Repository maintainers","Developers awaiting validation","CI platform operator"],"observable_state":"The controller can observe admissions by stable logical-update identifier, retry and rebase counts, queued and active jobs, queue age, runner utilization, timeout errors, and cancellations caused by superseding commits. Cascade risk is indicated when retry amplification and superseded-work rates exceed predeclared baseline bands while queue age or utilization remains above its opening threshold for multiple measurement windows.","consequence":"The retry feedback loop can consume runner capacity with repeated validation of logically identical updates, prolong validation for unrelated patches, and prevent the queue from draining even after the original workload burst ends.","affected_objective":"Preserve bounded, integrity-preserving CI validation availability for already admitted work and unrelated human-authored changes while allowing dependency automation to recover after saturation.","intervention":"Insert an admission boundary specifically between dependency-update automation and the shared merge queue. When retry amplification and saturation jointly cross the opening rule, enter an open state: reject new bot refresh, rebase, and rerun admissions with a stable machine-readable overload response and Retry-After value, while allowing already acknowledged jobs to finish. After queue health remains below a lower recovery threshold for a specified dwell period, enter a half-open state and admit limited probes stratified by repository, dependency ecosystem, and estimated test cost. Close fully only if probe outcomes and queue health remain acceptable; otherwise reopen. Separate opening and closing thresholds provide hysteresis.","structural_mapping":[{"archetype_element":"Flow","domain_realization":"Bot-generated pull-request admissions, rebase requests, and CI rerun requests entering the merge queue."},{"archetype_element":"Capacity constraint","domain_realization":"Finite CI runner slots, scheduler throughput, and merge-queue recomputation capacity."},{"archetype_element":"Coupling and cascade","domain_realization":"Timeouts and superseded commits prompt more bot activity, which consumes shared runners and delays unrelated validations, producing further expirations and retries."},{"archetype_element":"Controllable boundary","domain_realization":"A classifier and admission gate at the merge-queue API separates targeted automation traffic from acknowledged jobs and protected human traffic."},{"archetype_element":"Sampling","domain_realization":"The half-open state admits a small, stratified set of dependency-update probes instead of restoring the entire automation stream."},{"archetype_element":"Feedback","domain_realization":"Retry amplification, superseded-work rate, queue age, utilization, and probe results drive transitions among closed, open, and half-open states."},{"archetype_element":"Preserved invariants","domain_realization":"Acknowledged builds are neither silently dropped nor partially recorded; rejected requests receive predictable responses; tests are never bypassed; recovery can proceed automatically."}],"mechanism_mapping":[{"mechanism_slug":"half_open_state","role":"Creates a transitional recovery state between rejecting dependency-automation admissions and restoring full admission.","counterfactual_removal":"Without it, recovery would jump directly to full bot load, making an immediate recurrence indistinguishable from genuine stabilization."},{"mechanism_slug":"limited_probe","role":"Admits bounded test traffic to measure whether the queue can safely accept dependency-update work again.","counterfactual_removal":"Without probes, the controller would lack current evidence about downstream recovery and could reopen solely on stale aggregate metrics."},{"mechanism_slug":"canary_reintroduction","role":"Selects probes across repository and test-cost strata so recovery evidence is not confined to the cheapest or simplest updates.","counterfactual_removal":"Without stratified canaries, successful lightweight jobs could license reopening even though representative expensive jobs would recreate saturation."},{"mechanism_slug":"clean_rejection","role":"Returns an explicit overload verdict and retry timing instead of retaining rejected requests in an unbounded server-side queue.","counterfactual_removal":"Without clean rejection, hidden queued demand would continue accumulating and surge into the system during recovery."}],"causal_chain":["A workload burst or capacity loss raises merge-queue age and runner saturation.","Bots encounter timeouts, stale branches, or superseded builds and submit additional logically redundant work.","The added work consumes shared capacity and causes further delays and invalidations, forming a coupled retry cascade.","The joint saturation-and-amplification sensor opens the automation admission boundary.","Clean rejection stops new targeted work from adding to the shared queue while acknowledged jobs drain normally.","After lower recovery thresholds persist for the dwell period, the controller admits stratified limited probes in the half-open state.","Healthy probes and stable queue signals close the breaker; renewed saturation reopens it before full bot traffic returns."],"baseline":"A shared FIFO or priority merge queue with a fixed concurrency cap accepts bot refreshes and reruns whenever capacity is nominally available. During overload, requests wait or time out, and each bot independently decides whether to retry; operators may impose a manual freeze after noticing the backlog.","nearest_rivals":["Rate limiting: caps bot request frequency continuously, but does not necessarily sever the retry feedback loop during an active cascade or define a probe-based recovery state.","Backpressure: asks bots to slow down, but depends on heterogeneous clients honoring the signal and does not by itself provide a stateful admission boundary with hysteresis.","Bulkhead partitioning: reserves runner capacity by traffic class and limits lateral resource loss, but does not interrupt self-amplifying dependency-update traffic inside its partition.","Manual automation freeze: can stop admissions, but lacks sensor-driven opening, automatic probing, and feedback-governed recovery.","Adding CI runners: increases capacity but does not remove the coupling through redundant retries and superseded work."],"remaining_contrastive_claim":"The candidate is specifically a stateful, feedback-controlled interruption of dependency-update admissions: it opens only when saturation and retry amplification co-occur, preserves acknowledged work, and restores flow through representative half-open probes. A static quota, reserved pool, client advisory, manual pause, or capacity increase lacks that complete opening-and-recovery loop.","authority_safety":{"decision_authority":"The CI platform owner, under the repository organization's existing merge-queue operations policy, may configure the gate for authenticated dependency-automation identities.","authorized_first_step":"Run the opening rule and traffic classifier in read-only shadow mode against merge-queue telemetry; record hypothetical state transitions and probe strata without rejecting or rescheduling any request.","excluded_actions":["Cancel or discard already acknowledged CI jobs","Bypass required tests or branch protections","Block human-authored changes or designated emergency repair traffic","Modify pull-request contents, dependency versions, or repository settings","Apply the gate to unidentified traffic without validating actor classification","Create an unbounded server-side holding queue for rejected work"],"halt_rollback":"Disable shadow evaluation or return the gate to pass-through if actor classification captures protected traffic, telemetry cannot distinguish logical updates from retries, state transitions oscillate, or instrumentation affects scheduler operation. Configuration and decision logs must permit immediate rollback."},"negative_tests":{"strongest_counterevidence":"Backlog episodes are explained by a small number of intrinsically long or wedged jobs, while duplicate bot admissions occur after rather than before saturation and contribute negligible scheduled work; replay shows that opening the proposed boundary would not let the queue drain sooner.","problem_falsifier":"The logical-update arrival ratio remains near one, superseded-work and retry rates do not rise around backlog onset, or dependency-automation jobs do not share a capacity bottleneck with affected traffic. Any of these would break the required flow-capacity-coupling structure.","intervention_falsifier":"Shadow replay or a later authorized canary shows that rejection causes bots to retry through alternate endpoints, that half-open probes fail to represent restored load, or that queue health rebounds independently of the hypothetical gate while targeted admissions would not have changed.","risks":["Delayed dependency updates, including time-sensitive fixes","Misclassification of human or emergency work as bot traffic","Bots ignoring Retry-After and shifting retries to another interface","Threshold oscillation if hysteresis or dwell periods are inadequate","Probe selection biased toward inexpensive repositories","A misleading aggregate health signal hiding a saturated runner class","Reduced throughput after recovery because the breaker remains open too long"]},"next_evidence_step":"For ten working days, evaluate the classifier and state machine in read-only shadow mode. Pre-register opening and closing signals from an earlier non-overlapping baseline window, group arrivals by stable logical-update identifier, and inspect every hypothetical opening. For each event, replay admissions with targeted bot requests removed and compare queue-drain ordering, protected-traffic classification, state oscillation, and whether the proposed probe strata cover the observed workload. Stop after the fixed window and make no production admission changes in this step.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Generated solely from the supplied circuit-breaker record and computer-science domain card; no other proposals, cells, experiments, or prior-art sources were inspected.","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}