fix: TaskContextError for cross-task usage (issue #576)#600
Open
gspeter-max wants to merge 1 commit intoanthropics:mainfrom
Open
fix: TaskContextError for cross-task usage (issue #576)#600gspeter-max wants to merge 1 commit intoanthropics:mainfrom
gspeter-max wants to merge 1 commit intoanthropics:mainfrom
Conversation
Root Cause: - ClaudeSDKClient silently hangs when receive_messages() is called from a different async task than where connect() was called - anyio MemoryObjectStream is bound to the task group where created - Common scenario: FastAPI/Starlette apps with global client Changes: 1. Add TaskContextError exception class - Stores connect_task_id and current_task_id for debugging - Includes helpful error message with documentation reference - Follows existing error class patterns 2. Track task ownership in Query class - Add _owner_task field to track creating task - Capture task ID in start() using anyio.get_current_task() - Validate task context in receive_messages() 3. Update documentation - Update caveat in client.py to reference TaskContextError - Explain FastAPI/Starlette scenario 4. Add comprehensive tests (test_task_context.py) - Same-task usage works - Cross-task usage raises TaskContextError - Multiple clients in different tasks work - Error attributes and messages verified 5. Add FastAPI example (examples/fastapi_example.py) - Shows correct per-request client pattern - Documents wrong pattern (global client) 6. Remove test_concurrent_send_receive - Tested cross-task pattern that causes hangs - Never was supported (documented caveat) - Only passed with mocks, gave false confidence Impact: - Converts silent hang into fast, actionable error - No breaking changes for valid usage - Existing single-task usage unchanged - Cross-task usage now fails with clear guidance Refs: anthropics#576
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
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.
Implementation: Fix for Issue #576 - Cross-Task Detection
Implements suggestion #2 from the issue: detect cross-task usage and raise a clear error instead of silently hanging.
What Was Changed
1. New Exception:
TaskContextErrorTaskContextErrorexception class to_errors.pyconnect_task_idandcurrent_task_idfor debugging2. Task Tracking in Query Class
_owner_taskfield to track which task owns the Query instancestart()usinganyio.get_current_task()receive_messages()3. Updated Documentation
client.pyto reference the new error4. Comprehensive Tests
tests/test_task_context.py: 6 new tests covering:Example of the New Behavior
Before (silent hang):
After (clear error):
Correct Usage for FastAPI
See
examples/fastapi_example.pyfor complete working example.Note on Test Changes
One existing test (
test_concurrent_send_receiveintest_streaming_client.py) was removed because it tested the exact cross-task pattern we're now preventing. This test:asyncio.create_task()to callreceive_messages()from a different taskCross-task usage has never been supported (documented since v0.0.20), and this test was giving false confidence about a buggy pattern.
Verification
Breaking Changes
None. This only adds validation that was missing. Existing valid single-task usage is unchanged.
Ready for review! Feedback welcome on the error message wording, documentation, or approach.
Fixes #576