Repository navigation
[BUG]: orchestration stream goes silent until the final answer #225
Description
Activity
- added a parent issue
on Jun 11, 2026 Vetted 2026-07-17 with TTFB probes. Headers always land in under 10ms. With AURA_CUSTOM_EVENTS=true the first data event arrives in 6-8ms, before MCP init starts (init runs inside a spawned task now), so there is no init dead air in that mode. With custom events off, which is the default, nothing is written until the final answer arrives. In our runs that meant 11 seconds of silence on a 2-task plan, and a 20-task plan stayed silent for 63 seconds. The real problem is protocol shape in events-off mode rather than init cost, which makes the 1.5-6s framing wrong in both directions. Description rescoped to the events-off streaming gap. Worth knowing that the CLI hardcodes events on, meaning standalone users never see any of it.
- changed the title
[-]SSE connection dead air[/-][+][BUG]: orchestration stream goes silent until the final answer[/+]on Jul 17, 2026
With AURA_CUSTOM_EVENTS off (the default), a streaming orchestration request writes headers immediately and then nothing until the final answer. Measured on an instrumented main build (2026-07-17): headers land in under 10ms. A 2-task plan then stayed silent for 11 seconds and a 20-task plan for 63 seconds, with all data events arriving in a burst at the end.
With custom events on, aura.session_info goes out in 6-8ms, before MCP init even starts (Orchestrator::new runs inside a spawned task, factory.rs), so there is no init dead air in that mode. The CLI hardcodes events on and never sees this.
The original init-cost framing was wrong; the real gap is that events-off mode has no early signal at all. Scope: decide what the events-off stream should emit before completion, or accept that events-off users get OpenAI-shaped silence until the answer is ready.