fix(strix): disable streaming to route around contextual-orchestrator's stale invalid_stream_options rejection - #1447
Conversation
…'s stale invalid_stream_options rejection Every Strix scan org-wide has been failing closed with a 400 since Strix moved to contextual-orchestrator's orchestrator/free pool today (#1434): strix-agent 1.5.3 hardcodes stream_options.include_usage=true for every turn with no way to disable just that flag, and contextual-orchestrator's /v1/chat/completions unconditionally rejects that flag whenever tools are present -- which every Strix turn has. LLM_DISABLE_STREAMING=true is a genuine, documented strix env var that makes every turn a single non-streaming call, so stream_options is never sent and the rejection never fires. This restores the required Strix gate immediately at the cost of real-time SSE streaming. This is a temporary mitigation, not the fix: the honest usage-reporting path contextual-orchestrator's rejection guards against already works today for non-streaming tool-loop calls (confirmed by reading orchestrator.py and server.py directly) -- the rejection is a stale, factually-incorrect defensive check shipped alongside an unrelated fix. Tracking issue #1446 records what must land in contextual-orchestrator before this line is reverted. Full suite: 1903 passed, 1 skipped (unchanged from before this commit). Strix-specific contract tests: 68 passed.
|
Warning Review limit reachedNext included review available in 8 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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 |
| # tool-loop stream+include_usage rejection -- the honest usage-reporting | ||
| # path it guards already works today for non-streaming tool-loop calls) | ||
| # is merged and deployed. Tracking: #1446. | ||
| LLM_DISABLE_STREAMING: "true" |
There was a problem hiding this comment.
🔴 Streaming mitigation never reaches Strix
The quick gate omits LLM_DISABLE_STREAMING from its scanner environment, so streaming stays enabled. Gateway requests still fail with 400 responses.
Prompt for agents
The Run Strix workflow sets LLM_DISABLE_STREAMING=true, but scripts/ci/strix_quick_gate.sh creates child_env from an explicit allowlist before launching the Strix executable. That allowlist includes STRIX_REASONING_EFFORT and STRIX_LLM_MAX_RETRIES but not LLM_DISABLE_STREAMING, so the new setting is discarded. Propagate this setting through the trusted child-environment boundary and add a regression test proving the launched scanner receives it while unrelated environment variables remain excluded.
Was this helpful? React with 👍 or 👎 to provide feedback.
| # tool-loop stream+include_usage rejection -- the honest usage-reporting | ||
| # path it guards already works today for non-streaming tool-loop calls) | ||
| # is merged and deployed. Tracking: #1446. | ||
| LLM_DISABLE_STREAMING: "true" |
|
Closing in favor of #1448, which does the same mitigation ( Both PRs are explicitly temporary mitigations for the same root cause — see the note on #1448 for why the real fix (contextual-orchestrator#925, already up for genuine review, not a bypass) is likely to make either of these unnecessary shortly. Generated by Claude Code Generated by Claude Code |
|
Good catch, thanks — pushed Added it to the allowlist next to Generated by Claude Code |
Incident
Every Strix scan org-wide has been failing closed with a 400 since Strix moved to
contextual-orchestrator'sorchestrator/freepool today (#1434). Example failure: run 33307905354, job 99247611184.Root cause, confirmed by reading actual source (strix v1.5.3, openai-agents v0.19.4, and
contextual_orchestrator/server.py/orchestrator.pydirectly — not guessed):ModelSettings(include_usage=True)for every turn (strix/core/inputs.py::make_model_settings()), with no supported env var, CLI flag, or config key to disable just that flag while keeping streaming.contextual_orchestrator/server.py(~line 6583-6589) unconditionally rejectsstream=true+stream_options.include_usage=truewhenevertoolsorresponse_formatare present. Strix always sendstools, so every turn hits this. The check's own justification ("structured passthrough cannot emit usage SSE") is factually wrong: the tool-loop path already forces the upstream call to non-streaming and already captures real provider usage, and_chat_response_sse_chunksalready builds a genuineusage_source: "reported"SSE chunk from it — the honest-usage plumbing this check thinks doesn't exist already exists and already runs on this exact path.Fix (temporary mitigation)
Sets
LLM_DISABLE_STREAMING: "true"in the Strix job env instrix.yml. This is a genuine, documented strix env var (strix/config/models.py::_NonStreamingModel) that makes every turn a single non-streaming call, sostream_optionsis never sent and the gateway's check never fires. Restores the required Strix gate immediately at the cost of real-time SSE streaming.This is not the real fix — see #1446 for what must land in
contextual-orchestrator(removing/narrowing the stale rejection, since the honest usage-reporting path it guards already works) before this line is reverted.Developer experience
python3 -c "import yaml; yaml.safe_load(open('.github/workflows/strix.yml'))"— valid YAML.PYTHONPATH=. coverage run -m pytest tests -q→ 1903 passed, 1 skipped (unchanged from before this commit).test_strix_contextual_orchestrator_contract.py,test_strix_nvidia_nim_not_found_fallback.py,test_strix_openai_fallback_api_base.py,test_strix_repository_visibility_contract.py,test_strix_backend_unavailable_after_exempted_finding.py,test_strix_local_proxy_bootstrap_failure_is_classified.py,test_strix_model_behavior_error.py): 68 passed.User experience
None directly — CI-internal. Strix loses real-time streaming output during scans until the tracked contextual-orchestrator fix lands and this mitigation is reverted.
Test plan
strixrequired check will very likely fail on its own head —pull_request_targetexecutes the workflow definition from the trusted base branch, not this PR's head, so the fix in this diff cannot apply to its own check run (the documented trust-boundary catch-22 for PRs editingstrix.ymlitself,docs/pr-review-and-merge-procedure.md). This is expected and not a defect in the diff.Tracking: #1446
Generated by Claude Code