Repository navigation
[BUG]: one stuck progress send freezes progress for all requests #230
Description
Activity
- added a parent issue
on Jun 11, 2026 Vetted 2026-07-17, static. request_progress.rs:84-93 still holds the RwLock read guard across send().await, while both sibling brokers in tool_event_broker.rs clone the sender and drop the guard first. When a send blocks (the condition #229 reproduces), the pinned guard starves subscribe/unsubscribe on the process-global broker, so the blast radius is cross-request, not per-request. Not reproduced live: that needs more than 1024 progress notifications against a wedged consumer, but the blocking condition itself is the one demonstrated in #229. Description updated.
- changed the title
[-]request_progress.publish lock+await[/-][+][BUG]: one stuck progress send freezes progress for all requests[/+]on Jul 17, 2026
RequestProgressBroker::publish holds its RwLock read guard across sender.send().await (request_progress.rs:84-93). The two brokers in tool_event_broker.rs handle the same situation by cloning the sender and dropping the guard before awaiting; this one does not.
The broker is process-global, which is what makes this worse than a per-request stall. A single blocked send (see #229 for the reproduced blocking condition on a sibling channel) pins the read guard indefinitely. Every subscribe and unsubscribe on the write side queues behind it, so unrelated requests stop being able to register or clean up progress channels. Verified against main 2026-07-17. Not reproduced live, since that needs 1024+ progress notifications against a wedged consumer.