Skip to content

fix(ai_chat): forward conversation_timeout on the start path - #84

Closed
grandcamel wants to merge 2 commits into
signalwire:mainfrom
grandcamel:fix/gateway-start-timeout
Closed

fix(ai_chat): forward conversation_timeout on the start path#84
grandcamel wants to merge 2 commits into
signalwire:mainfrom
grandcamel:fix/gateway-start-timeout

Conversation

@grandcamel

Copy link
Copy Markdown
Contributor

Summary

ChatGateway.prepare() puts conversation_timeout into the start params, but the HTTP dispatch in router() rebuilt the create_conversation call with only id and config_url — silently dropping the timeout. A gateway configured with conversation_timeout=900 would tell the browser "timeout": 900 (via effective_timeout) while the service kept its own 3600-second default: the page schedules its "your next message starts a new conversation" warning around a number the service never enforces.

The chat path was unaffected (it streams params through verbatim via raw_post), which made the drift invisible to any conversation opened by a first message rather than by start.

Fix

Forward params.get("conversation_timeout") as the client's timeout= kwarg on the create_conversation dispatch. AIChatClient.create_conversation already accepted it and maps it onto the wire as conversation_timeout; None is skipped, so gateways without a configured timeout emit exactly what they did before.

Test

test_start_forwards_the_configured_timeout_upstream drives the real HTTP dispatch (ASGI harness + recording stub service) rather than prepare()prepare() was already correct, so a unit test at that level would have passed with the bug in place. Verified red without the fix (KeyError: 'conversation_timeout' on the stub's received params), green with it. The test also pins the auto-create chat path so the two paths can't drift apart again.

Note: local FMT gate currently fails on pre-existing formatting in gateway.py/function_result.py — fixed in the companion CI-gates PR; merge that one first.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MgA3KeCEPMKMJVvroZY1wV

grandcamel and others added 2 commits August 12, 2026 14:53
prepare() puts conversation_timeout into the start params, but the HTTP
dispatch rebuilt the create_conversation call with only id and config_url,
silently dropping it. A gateway configured with conversation_timeout=900
told the browser 900 (via effective_timeout) while the service kept its
own 3600 default — the page schedules its idle warning around a number
the service never enforces. The chat path was unaffected (raw_post
streams params verbatim), which kept the drift invisible for
conversations opened by a first message.

The regression test drives the real HTTP dispatch through the ASGI
harness — prepare() was already correct, so a prepare()-level assertion
would have passed with the bug in place. Verified red without the fix,
green with it; it also pins the auto-create chat path so the two paths
cannot drift apart again.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MgA3KeCEPMKMJVvroZY1wV
The config puts tests in scope on purpose ("a new untyped test fails the
gate"), so an unannotated test function reds TYPECHECK on main.
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