Repository navigation
fix(runtime+remote): turn-cancel state cleanup and streaming error surfacing (F2/F3/F4) - #672
Conversation
_response_error_detail crashed with httpx.ResponseNotRead when rendering an error from an unread streaming response, masking the real failure (a live 409 was invisible). Read the body bounded (byte cap + 5s threaded reader timeout), surface 'HTTP <code>: <detail>' with a bounded plain-text fallback, and never crash while rendering an error. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ks (F3/F4)
Live-evidenced on o6n: a client disconnect during a streaming prompt left
run rows cancelled while process-local Session.turn_in_progress/task never
cleared (permanent 409 'Turn already in progress'); separately, pipeline
fork rollback only ran under 'except Exception', so cancellation left the
cached runtime on a dirty fork tape whose later persistence hit the durable
_bind_tape guard ('session tape target cannot be rebound'), bricking the
session.
- pipeline: fork rollback also on cancellation/BaseException, best-effort
and original-exception-preserving; ctx.tape restored to the stable tape
- lifecycle: RuntimeTurnSessionState.finalize(turn_finished=...) clears
admission when the owning task finished/cancelled, preserves it while
the owned turn is still running (existing contract test unchanged)
- http_server: stream cleanup cancels by liveness (covers GeneratorExit/
aclose), awaits the task, routes clearing through finalize, shields the
recovery persist, skips no-op finalization
Red-first gating tests for all failure modes.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 5 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (10)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
Reopens #671 (auto-closed when the head branch was deleted after a blocked merge attempt; identical content, prior CI green: test + CodeRabbit pass). Fixes F3 (permanent 409 after stream disconnect: liveness cancel + finalize-routed admission clearing, running owned turns preserved), F4 (cancelled fork tape bricking sessions: rollback on BaseException, _bind_tape untouched), F2 (streaming error rendering crash: bounded read, HTTP code + detail, never crashes). Plain bug fixes under ADR-0055/0068, codex-delegated, 2-round subagent review to 0 P1/P2, red-first gating tests. Full suite 4059/8/20. Evidence: docs/dogfood/SEMANTIC_MEMORY_RUN_EVIDENCE.md
🤖 Generated with Claude Code