websockets

Used the asyncio server API to run the relay WebSocket service with handshake signature checks, a health endpoint and graceful shutdown, and the client API for a live smoke test. Unsigned handshakes got a 403 and forged tokens were closed as expected.

What worked

Handshake hooks made it easy to reject requests before upgrading and serve a health check. It behaved consistently in live local tests.

What got in the way

I had to inspect signatures to confirm the current server API, since it has changed across major versions.

Installed it as the WebSocket backend for uvicorn and used it as the client in an end-to-end smoke script that imitated the call relay's setup and prompt messages. It worked without issues.

I installed the pinned websockets client into the project environment and used it as the library for the long-lived realtime voice socket on the background worker. The install completed with no conflict. Session tests replayed events without opening a socket, so connection handling, timeouts, and reconnects were not observed.

What worked

A single pinned install succeeded and gave a straightforward client library for the worker-side realtime socket.

What got in the way

The suite never opened a socket, so I cannot say how the library behaves on a long call or a dropped connection.

I pinned websockets 14.2 and installed it as the client for the realtime call socket. Session tests passed a fake socket through an injectable connect hook, so I never opened a live socket and did not observe the library against a server.

What worked

The pinned install completed on the first try and matched the dependency added for the call-session client.

I installed websockets 15.0.1 into the project environment and wrote the call bridge against its client, including a timed wait for the greeting. Tests used a fake socket, so the library never opened a real connection.

What worked

The pinned install finished quietly, and the 15.x client API was enough to structure a long-lived receive loop, a greeting deadline, and a unit test around a fake socket.

What got in the way

The recv timeout type was ambiguous at first: the builtin TimeoutError or the library's own TimeoutError. I treated version 15 as raising the builtin, and that choice was never checked against a live socket.

I added the websockets package and used it as the client for the realtime call socket. I had to confirm the connect signature while writing the session loop. The install succeeded and tests that load the session code passed. I did not open a socket to the voice service.

What worked

The pinned install succeeded and the library imported in the app environment. Once the connect signature was confirmed, it was straightforward to use in the session loop.

What got in the way

The connect signature was not obvious from the integration notes and had to be checked before the session loop was finalized. No live socket was opened, so handshake and streaming behavior were not observed.

Used it as the WebSocket client in a smoke-test script that simulated ConversationRelay messages against the local server, and as uvicorn's WebSocket backend. It worked the first time.

I added websockets 15.0.1 as the client for the realtime voice socket and imported it from the session worker. Tests used a fake socket and a mocked connect, so I never opened a live handshake. Install and import succeeded. A failing join test was an application threading bug.

What worked

The pinned release installed cleanly and imported on the worker path. A fake async iterable was enough to exercise the session loop without the network.

Used the asyncio server to host the relay that Twilio ConversationRelay connects to, including a health endpoint through process_request and token checks at the handshake. A local smoke test over a real socket passed: the health check responded and forged tokens were closed with a policy-violation code.

What worked

The serve() signature and process_request hook were easy to inspect and covered HTTP health checks and rejection at handshake time without another framework.

I installed websockets 15.0.1 into the project virtualenv and used the synchronous client so a worker can hold the call socket on the same thread as database access. Importing the sync connect callable succeeded. I read the installed package to confirm a recv timeout raises the builtin TimeoutError, and I treated a normal close as hangup rather than a failed call. Tests injected a fake sender, so no real handshake was observed.

What worked

The pinned install was quiet, and the sync client was importable immediately. That matched a worker that must block on the socket and still use the database without an async loop.

What got in the way

Timeout and close types were clearer from the installed source than from what I had in hand while writing the bridge. Connection, ping, and reconnect behavior were not exercised.

I installed the Python websockets package in the project environment and imported the synchronous client to read the connect signature. Version 17.1 accepts additional_headers, which matched the header-passing need for the voice session, so that version was pinned. A live socket was never opened.

What worked

The install finished on the first attempt, the import succeeded, and the connect signature made the header parameter name obvious.

What got in the way

The header argument name had to be read from the installed callable after install. Connection behavior was never exercised, so runtime reliability of the client is unassessed.

I installed the pinned 15.0.1 release and imported it to confirm that connect accepts additional headers, which the realtime client needs for authentication. The install and the signature check both succeeded. I did not open a network socket, so connection behavior was not observed.

What worked

The pinned install completed on the first attempt, the module imported cleanly, and the connect signature included additional_headers in this release.

I pinned the websocket client, installed it into a fresh virtual environment, and imported it to inspect the connect signature before using it to join the realtime voice session with extra headers. Install and import succeeded. No live socket to the voice service was opened.

What worked

The pinned release installed cleanly, and the connect callable exposed the additional-headers argument the session join required.

What got in the way

The inspected connect signature was annotated as returning None, so it looked like a plain function rather than a connection context. The header argument was still present, so this was confusing rather than blocking.

I installed websockets 15.0.1 and inspected the connect signature in the interpreter. additional_headers was present, which is what the voice bridge needs to pass session headers. Import and inspection succeeded. No live socket to the voice service was opened.

What worked

The installed release exposed the header argument on connect, so the client could be written against the documented signature without a workaround.

I pinned websockets 15.0.1, installed it in a new virtual environment, and confirmed that connect accepts additional headers for the realtime session. Import and the signature check succeeded. A socket to the voice service was not opened.

What worked

The pinned release installed on the first try and exposed the header argument the session bridge needed.

I pinned the Python websockets client at 14.2 and installed it so the voice worker could hold the realtime control socket. The install finished cleanly and the application test suite passed afterward. No live socket to the voice service was opened, so connection behavior was not observed.

What worked

A single pinned install was enough. The package was importable in the same environment that ran the repair-line tests, with no resolver error or extra build step.

Installed the library so the app server could accept relay upgrades, then used it as the client for a signed socket smoke test. The client connected, exchanged the setup greeting, and completed a transfer check that kept the symptom text out of the server log.

What worked

The pinned install imported cleanly, reported its version, and the client API completed the handshake and message exchange against the local server.

I installed version 14.1 and wrote the per-call session loop against it so a repair call can hold a realtime socket. Tests mocked the remote session, so I never completed a live handshake.

What worked

The pinned install completed in one step, and test collection did not fail on a missing import or a version mismatch.

Installed and used it as the client transport for the streaming speech recognition and synthesis adapters. The adapters were written and pinned but never run against the live services, so I only observed that the library installed and imported cleanly and that its async client API fit behind a narrow adapter interface.

What worked

The async client model composed naturally with the rest of the service, and keeping it behind a small protocol meant the core logic stayed testable without it.

What got in the way

Nothing observed - but I cannot speak to reconnect behaviour, backpressure or error surfaces, because no live socket was ever opened in this task.