fix(voice): raise the background turn ceiling from 90s to 180s - #5536
Conversation
90s was aborting real answers. On staging the same "summarize my emails" request finished in ~53s on one call and was still running past 90s on the next, where it hit the ceiling and the caller got "Sorry — I couldn't finish that request just now" instead of their summary. Nothing was wrong on that call; a big inbox is simply more Composio round-trips than a small one. This ceiling does not govern how long the caller waits - the ack deadline caps that at ~8s and hands off to chat. It governs the deferred half that finishes in the background and is read aloud if the call is still up, so a higher value costs a slow turn nothing and buys it the chance to land at all. Requires the paired relay change (tinyhumansai/backend#1274): the relay's own timeout must stay above this one, or it cuts a still-streaming turn first and reports a relay failure for a turn that was working.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe background voice-turn timeout increases from 90 to 180 seconds. Documentation describes the deferred execution window and coordination with the backend relay timeout. ChangesVoice Turn Timeout
Estimated code review effort: 1 (Trivial) | ~2 minutes Mergeability Score: 🔵 Low · up to The longer background timeout should allow slow voice requests to complete, but merge readiness depends on deploying the relay timeout above 180 seconds and accepting the bounded risk of longer resource occupancy and queueing during sustained load. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
2 participants
Summary
TURN_TIMEOUT_SECS, from 90s to 180s.Problem
90s was aborting real answers. Observed on staging across two consecutive calls asking the same thing ("Can you please summarize my emails?"):
conv_6201kzxwc51ye9682qzgh8wa597r— the deferred turn finished in ~53s, the read-back landed att=58, and the summary was spoken (519 TTS chars).conv_2001kzxw8r84f82tcpkr7pjyrrd5— the same request was still running past 90s, hit the ceiling, and the caller got"Sorry — I couldn't finish that request just now."instead of their summary. No read-back message appears in that transcript at all.Same code, same path, same question — the difference is how many Composio round-trips the inbox needed. A hard ceiling that a normal request can cross is a failure the user cannot distinguish from a broken feature.
Solution
TURN_TIMEOUT_SECS90 → 180, with the reasoning recorded on the constant.This ceiling does not govern how long the caller waits —
VOICE_ACK_DEADLINE_SECScaps that at ~8s and hands off to chat. It governs the deferred half: the orchestrator keeps working after the voice turn closes, and its answer is delivered into chat and read aloud if the call is still up. So a higher value costs a slow turn nothing and buys it the chance to land at all.Submission Checklist
N/A: constant change. The value is a timeout ceiling with no branch of its own; the paths around it (deferred delivery, failure notice, read-back) are covered by the existingrealtime_harnesstests, which pass unchanged.N/A: no new executable lines(one constant, the rest doc comment).N/A: behaviour-only change## Related—N/A: no matrix rows affectedN/A: no release-cut surface changeCloses #NNN—N/A: follow-up, #5399 stays open for the remaining workImpact
Desktop only. No API, schema, or storage change.
Merge order matters. The relay's
DEFAULT_TIMEOUT_MSmust stay above this ceiling — whichever side is lower decides which error the user sees. tinyhumansai/backend#1274 raises it to 185s and should land first or together. Merging this alone against a 95s relay would cut a still-streaming turn at 95s and report a relay failure for a turn that was working.The remaining latency work is unchanged and still open under #5399: the ~10.6s pre-model path (per-turn orchestrator rebuild, integration catalogue, memory recall) is why turns defer at all. This raises the ceiling; it does not make turns faster.
Related
Relates to #5399. Pairs with tinyhumansai/backend#1274. Follow-up to #5489.
Summary by CodeRabbit