fix(bargein): error when no interruption threshold is known - #6034
Merged
chenghao-mou merged 2 commits intoJun 11, 2026
Merged
Conversation
The local THRESHOLD = 0.656 constant only fed the observability-only effective_threshold log; the server makes the actual interruption decision. A hardcoded fallback can silently disagree with the server's real default, which is misleading in exactly the case you'd debug. Drop the constant: _resolve_effective_threshold now returns None when neither a user override nor a server default_threshold is known, and we emit a warning so the unknown-threshold case is surfaced rather than papered over with a plausible-but-wrong number. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
u9g
approved these changes
Jun 9, 2026
If neither the user nor the server provides a threshold, raise a non-retryable APIStatusError instead of warning and continuing. Validate before the observability log so we don't emit a "session created" line with a null threshold immediately before failing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
theomonnom
approved these changes
Jun 10, 2026
chenghao-mou
added a commit
that referenced
this pull request
Jun 11, 2026
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Drops the local
THRESHOLD = 0.656constant from the adaptive interruption detector and errors the stream when no threshold is known.Why
The server makes the actual interruption decision. The client only ever used
THRESHOLDas the last fallback in_resolve_effective_threshold(), which feeds the observability-onlyeffective_thresholddebug log. A hardcoded client-side fallback can silently disagree with the server's real default — misleading in exactly the situation you'd be debugging.When the user doesn't override
threshold, the client sends nothing and the server applies its own default; the server-reporteddefault_thresholdonsession.createdis optional. The only genuinely broken case is when both are absent — no user override and no server default — which we now treat as a hard contract violation and fail fast.Changes
THRESHOLDconstant._resolve_effective_threshold()now returnsfloat | None(user override → server default →None).session.createdwith no user override and no serverdefault_threshold, raise a non-retryableAPIStatusError(status 500) so the stream fails fast instead of silently running with an unknown threshold.TestWsSessionCreatedMissingThresholdcovering the fail-fast path.This is a follow-up cleanup to #5946.
Test plan
pytest tests/test_interruption/— 14 passedruff check— clean🤖 Generated with Claude Code