RStudio Connect load balancer and Shiny session lifecycle: can in-flight sessions survive a version redeploy?

Question

We run a small Shiny application behind RStudio Connect's built-in load balancing and want to deploy new versions without kicking out users who are mid-session. My understanding is that each deployment creates a new content bundle with its own package library, and that Connect tears down the existing R processes rather than migrating them.

The uncertainty is at the boundary between the Connect scheduler and the Shiny runtime. Shiny's reactive state lives in R process memory, and I have not found a supported way to serialize reactive values, input bindings, or renderers across process boundaries. I also believe session$onSessionEnded only fires on clean client disconnects, not on server-initiated termination during a deploy, which would mean cleanup code never runs. Assume a recent Connect release (2023.09 or later).

Specific questions:

Does RStudio Connect expose any session-draining or graceful-shutdown hook before it stops an application's R processes during a redeploy?
Can the connectapi package (or the Server API) enumerate or signal individual active user sessions, or is teardown always unconditional?
If externalizing state (e.g., Redis via redux) is the only path, is there a documented reconnect flow so returning clients rebuild UI state against the new version?

Tasadduq Burney · Answer

Answer
No – in‑flight Shiny sessions are terminated when RStudio Connect redeploys a new version of the app.
Confirmed facts (based on Connect behavior)

Each deployment creates a new content bundle with its own R process library.
Connect stops the old R processes immediately; there is no graceful‑shutdown or session‑draining hook exposed for Shiny apps.
The Server API (and the connectapi package) lists apps, users, and deployment status but does not provide endpoints to enumerate or signal individual Shiny sessions.
session$onSessionEnded fires only on normal client disconnects; it is not invoked when the server process is killed during a redeploy, so cleanup code does not run.

Likely explanation
Connect’s load balancer routes traffic to the newest bundle as soon as the new R processes are ready. Because Shiny’s reactive state lives only in the R process memory and there is no built‑in mechanism to serialize or transfer that state, the balancer cannot migrate sessions; it simply switches the routing table and the old processes are killed.
Steps needed for zero‑downtime user experience

Externalize any state that must survive a redeploy (e.g., store reactive values, input bindings, or cached data in Redis, a database, or a file store).
At app startup, check the external store for a key tied to the current session ID (or a user‑specific identifier) and repopulate UI widgets accordingly.
Implement a reconnect detection routine: if the restored state is missing or stale, fall back to the default UI.
Optionally add a session$onSessionEnded handler that writes a cleanup marker to the external store; note that this handler will not run during a server‑initiated kill, so rely on the startup check rather than the handler for state recovery.
Verify the flow: start a session, trigger a redeploy via Connect, then reload the page and confirm that the UI reflects the previously stored values.

Missing diagnostic detail
Do you already persist any reactive state outside the R process? If you do, the recommendation is to verify that the reconnect logic works; if you do not, externalizing state is the only path forward.

RStudio Connect load balancer and Shiny session lifecycle: can in-flight sessions survive a version redeploy?

1 answer

Answer

Confirmed facts (based on Connect behavior)

Likely explanation

Steps needed for zero‑downtime user experience

Missing diagnostic detail

Your perspective belongs here.

0 question comments