fix(core): prevent hanging turn/start due to websocket warming issues

[owenlin0]

Description

This PR fixes a bad first-turn failure mode in app-server when the startup websocket prewarm hangs. Before this change, initialize -> thread/start -> turn/start could sit behind the prewarm for up to five minutes, so the client would not see turn/started, and even turn/interrupt would block because the turn had not actually started yet.

Now, we:

• set a (configurable) timeout of 15s for websocket startup time, exposed as websocket_startup_timeout_ms in config.toml
• turn/started is sent immediately on turn/start even if the websocket is still connecting
• turn/interrupt can be used to cancel a turn that is still waiting on the websocket warmup
• the turn task will wait for the full 15s websocket warming timeout before falling back

Why

The old behavior made app-server feel stuck at exactly the moment the client expects turn lifecycle events to start flowing. That was especially painful for external clients, because from their point of view the server had accepted the request but then went silent for minutes.

Configuring the websocket startup timeout

Can set it in config.toml like this:

[model_providers.openai]
supports_websockets = true
websocket_connect_timeout_ms = 15000

[owenlin0]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d880b09652

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[pakrym-oai]

Why is this needed? Don't we auto retry?

[owenlin0]

so a retry does happen but at the turn level, not by creating a brand new websocket client from scratch

So when a request fails, Codex retries the same turn using the same turn-scoped session object. If we do not call reset_websocket_session(), that retry can carry leftover websocket state from the timed-out attempt and act like it is continuing a connection that never really came up.

[pakrym-oai]

this is random