Missing timeout configuration for Reflex server-side component state

Short answer

No — as of the Reflex 0.x series (formerly Pynecone), there is no supported configuration option such as a state-idle-timeout in rxconfig.py or on rx.App. State lives in the backend keyed by session token, and the framework retains it while the WebSocket connection is open. Expiration is something you add yourself, and the only safe place to do it is at connection boundaries, not mid-session.

Why purging live state breaks reactivity

Reflex's reactivity loop assumes the server-side state object for a connected session always exists. If a cleanup job deletes a session's state while its WebSocket is still open, the next frontend event arrives referencing state the server no longer has. Depending on version and store, that surfaces as a fresh default state (silently discarding user data) or an exception in the event handler. Neither is a graceful timeout — it is a consistency violation. This is the likely explanation for the interference you observed with custom middleware; treat it as expected behavior, not a bug you can configure around.

A pattern that preserves consistency

The reliable approach is to expire only disconnected sessions:

1. Track connection lifecycle. Record a last-seen timestamp per session token, updated on connect and disconnect (for example, in an on_connect/on_disconnect style hook or middleware that observes the WebSocket close event).
2. Run a periodic sweeper that deletes only sessions whose WebSocket has been closed for longer than your TTL (e.g., 15–60 minutes). Never touch sessions with an open connection.
3. If you use an external store such as Redis for scale-out, set the native TTL on the session key and refresh it on activity, so expiration is atomic and handled by the store rather than your code racing the framework.
4. For genuinely idle-but-connected clients, decide at the application level: have the frontend save draft data and disconnect after inactivity, rather than having the server delete state out from under it.

Verification

• Load-test with N idle connections, wait past the TTL, and confirm via htop or a Prometheus process exporter that memory drops only after disconnects.
• After the sweeper runs, reconnect a client and confirm it receives a fresh state without server-side errors in the logs.
• Keep one connection active through a sweep cycle and confirm its events still mutate state correctly — this catches an over-aggressive selector.

Caveats

Exact hook names and the pluggable state-store API have changed across Reflex releases, so verify against the changelog for your installed version (pip show reflex) before relying on any specific middleware signature. The one detail that would change this recommendation: whether your deployment is single-process or multi-worker — multi-worker setups effectively require the external-store-with-TTL route, since in-memory state is not shared.