Skip to content

fix: use threading.RLock for in-memory server singletons - #1162

Open
mykytanetipa wants to merge 2 commits into
a2aproject:mainfrom
mykytanetipa:fix/eventloop-safe-locks-inmemory-queue-active-task-registry
Open

fix: use threading.RLock for in-memory server singletons#1162
mykytanetipa wants to merge 2 commits into
a2aproject:mainfrom
mykytanetipa:fix/eventloop-safe-locks-inmemory-queue-active-task-registry

Conversation

@mykytanetipa

Copy link
Copy Markdown
Collaborator

The in-memory server singletons guard their state with an asyncio.Lock, which binds to the first event loop that awaits it. A server that uses these singletons from more than one event loop then hits "RuntimeError: ... is bound to a different event loop" (or a cross-loop hang).

Replace the asyncio.Lock with a loop-agnostic threading.RLock in InMemoryQueueManager, ActiveTaskRegistry, InMemoryTaskStore, InMemoryPushNotificationConfigStore, and the request handler's _running_agents guard, moving awaited calls outside the lock so each critical section is a pure in-memory dict operation.

Behavior is unchanged for single-loop servers; only the private lock attribute's type changes.

Tests: added tests/server/test_cross_event_loop_locks.py (cross-loop regression) and updated the test_init lock-type assertion.

@mykytanetipa
mykytanetipa requested a review from a team as a code owner August 4, 2026 07:11
@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown

🧪 Code Coverage (vs main)

⬇️ Download Full Report

No coverage changes.

Generated by coverage-comment.yml

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants