serialize websocket requests directly

[jif-oai]

Why

Responses WebSocket requests were encoded in two steps: first into a full serde_json::Value, then again into the JSON string sent over the socket.

That walks the full request twice and keeps an extra JSON tree alive. These requests can contain the complete conversation history and tool schemas, so the extra work grows with the request size.

What changed

• serialize ResponsesWsRequest directly to the wire string
• pass that string through the existing WebSocket stream and send path
• keep the existing error mapping, tracing, send timeout, and telemetry behavior
• compare the new wire JSON with the previous to_value payload in a focused test

Performance

I measured both paths in an optimized temporary test using a 6,324,180-byte request: 4 MiB of history plus 256 tools with 8 KiB descriptions. Each path ran 100 times.

• previous to_value + to_string: 209 ms total, 2.09 ms per request
• direct to_string: 174 ms total, 1.74 ms per request
• difference: about 17% faster, or 0.35 ms per request

The direct path also removes one full temporary serde_json::Value tree. For this mostly string-backed payload, that avoids roughly one payload-sized copy plus the JSON node overhead. The exact memory saving depends on the request shape.

The temporary benchmark was removed before committing.

Validation

• just test -p codex-api — 125 passed
• just fix -p codex-api

[jif-oai]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Chef's kiss.

Reviewed commit: fe58231e02

ℹ️ 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".