Skip to content

fix(governance): R1 — COMPLEX outer/inner timeout coherence - #36818

Open
drussell23 wants to merge 1 commit into
mainfrom
fix/governance-r1-complex-timeout-coherence
Open

fix(governance): R1 — COMPLEX outer/inner timeout coherence#36818
drussell23 wants to merge 1 commit into
mainfrom
fix/governance-r1-complex-timeout-coherence

Conversation

@drussell23

Copy link
Copy Markdown
Owner

Summary

Aligns the orchestrator outer Iron Gate wait_for budget with the inner fallback thinking cap for COMPLEX-route GENERATE, so ops are not cancelled at ~255s (240s + grace) while fallback advertises a 360s cap.

Context

Rubric soak bt-2026-05-18-015317 showed GENERATE dying at 255s with CancelledError despite max_cap=360s on the fallback path — outer/inner timeout mismatch (Task #88b class).

Test plan

  • pytest tests/governance/ (touched timeout coherence pins)
  • Re-soak psf-only with OUROBOROS_BATTLE_MAX_WALL_SECONDS set; confirm failure mode moves past 255s if providers still exhaust

Made with Cursor

Soak bt-2026-05-18-015317: psf routed COMPLEX (Trace-1 validated) but
GENERATE died with CancelledError at ~255s — the OUTER Iron-Gate
_gen_timeout for COMPLEX (JARVIS_GEN_TIMEOUT_COMPLEX_S=240 +
JARVIS_OUTER_GATE_GRACE_S=15 = 255s) killed the call BEFORE the INNER
fallback's 360s thinking window could complete. More COMPLEX budget on
the inner path is moot if the outer gate fires first (same class as
Task #88b, now on the COMPLEX+SWE-bench path). Falsifies the earlier
"timeouts resolve with COMPLEX budget" assumption — empirically.

Root fix — single source of truth, no duplication, no per-path drift:
* candidate_generator: extract the inline _call_fallback thinking
  predicate + cap into module-level gen_call_likely_thinking() +
  fallback_thinking_cap_s(); refactor _call_fallback to consume them
  (behaviour-identical for _max_cap; removed locals have zero
  downstream refs).
* generate_runner (the LIVE phase-dispatcher path) + orchestrator
  (dead-twin parity): at the _gen_timeout birth seam, BEFORE the
  deadline the outer wait_for derives from, floor
  _gen_timeout = max(_gen_timeout, fallback_thinking_cap_s()) when
  gen_call_likely_thinking(route, task_complexity). Both inner and
  outer now consume the SAME predicate+cap → outer >= inner holds by
  construction. Floor runs BEFORE adaptive scale_gen_timeout (also
  added to generate_runner for orchestrator parity) so one coherent
  value propagates to deadline + outer wait_for + tool-loop budget.
  Fail-open to route base; lazy import (no module-load coupling).

Spine: tests/governance/test_r1_timeout_coherence.py (14 — predicate
truth-table incl. case-insensitive + psf case; cap default/env/invalid
-fallback; coherence invariant max(240,360)>=360 (>255 death point);
AST pins: candidate_generator uses shared helper not inline literal;
generate_runner + orchestrator floor BEFORE the GENERATE deadline they
feed and BEFORE adaptive scale; no duplicated predicate on either
path). 52 adjacent parity tests green (route/classify runner parity +
op-isolation). 18 candidate_generator TestExhaustionInstrumentation
failures are PRE-EXISTING (stash-isolated: identical on clean
origin/main) — flagged, not bundled, per clean-scope discipline.

R2 (controlled rubric soak: serial, urgency=high, sensor-throttled)
runs after this merges. Tasks #7/#8 stay ratified-held.

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

Copy link
Copy Markdown

📊 PR Size Analysis

Size: M
Files Changed: 1
Lines Added: +245
Lines Deleted: -0
Total Changes: 245

Review Checklist

  • All tests passing
  • Code follows project style guidelines
  • Documentation updated if needed
  • No sensitive data exposed
  • Breaking changes documented

@github-actions

Copy link
Copy Markdown

🚨 CI/CD Failure Detected

The Environment Variable Validation workflow failed for this PR.

Action Required

A tracking PR has been automatically created to help resolve this issue:
🔗 #36819

Quick Links

Please review the analysis and implement the suggested fixes.


🤖 Auto-generated by JARVIS CI/CD Manager

@github-actions

Copy link
Copy Markdown

🚨 CI/CD Failure Detected

The Database Connection Validation workflow failed for this PR.

Action Required

A tracking PR has been automatically created to help resolve this issue:
🔗 #36820

Quick Links

Please review the analysis and implement the suggested fixes.


🤖 Auto-generated by JARVIS CI/CD Manager

@github-actions

Copy link
Copy Markdown

🤖 CI/CD Pipeline Results

Status: success
Branch: 36818/merge
Commit: 9b35863afe7a296dbf7b28d82131b10c1aa0faae

Pipeline Stages

  • Code Quality: ❌
  • Build & Test: ❌
  • Architecture: ❌
  • Security Scan: ❌

View full workflow run

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant