The deploy that doesn't hang up on grandma.

The CareOS Go API holds a WebSocket open to every Companion in the field. Voice frames stream in, TTS frames stream out, and parallel goroutines handle vision uploads and command dispatch. A single bedside chat can touch four or five goroutines at once, all coordinating on one session. When we ship a new build, none of them can be ripped out mid-sentence.

Context as the spine

Every session is rooted in a `context.Context` derived from the server's lifecycle context. When a device connects, we call ctx, cancel := context.WithCancel(server.RootCtx) and hand that ctx to every goroutine the session spawns — the audio reader, the synthesizer, the vision fanout, the command queue. Every blocking call in our stack takes a ctx: conn.Read(ctx), tts.Synthesize(ctx, utterance), pubsub.Publish(ctx, msg). Nothing waits on a bare channel without also selecting on ctx.Done().

On SIGTERM, the server cancels RootCtx and stops accepting new sessions. Cancellation propagates down the tree. The audio reader unblocks and returns. The synthesizer finishes the current utterance — we hold a small shutdownCtx with a deadline for in-flight TTS so the sentence completes — and then exits its loop. The WebSocket handler drains its send queue, writes a clean `CloseGoingAway` frame with a reconnect hint, and closes the socket.

What the device hears

Because the close is clean, Companion's reconnect logic treats it as a planned event, not a crash. It waits a beat, reopens against the new pod, and resumes the conversation with session state restored from Redis. From the bedside, the sentence finishes, there's a half-second pause, and the next reply lands.

The product effect: we deploy CareOS during the day, multiple times a week, while real conversations are happening. No abrupt silences, no scheduled maintenance windows, no family ever telling us the device hung up on grandma.