How can stateful connections be managed during a Cloud Run zero-downtime migration?

The goal is to perform a zero‑downtime migration of a small application by deploying a new Cloud Run revision and gradually shifting traffic via traffic splitting, keeping the service URL stable.

Because Cloud Run does not provide session affinity and treats each request independently, long‑lived connections (e.g., WebSocket, persistent HTTP, or database pools) that are bound to a specific revision may be terminated when traffic is moved, and any in‑memory session state is lost unless externalized.

What strategies exist for externalizing session state so that both revisions can access it? Can connection‑draining or keep‑alive mechanisms be used to allow existing connections to finish before they are terminated? Is it acceptable to rely on client‑side reconnect logic, or must the application be redesigned to be connection‑stateless?