Reflex: cached @rx.var or on_load event handler for keeping deployed page data fresh?

Answer

For a page that tolerates a few‑minute staleness but must not serve pre‑deployment data, the safest pattern is to fetch the data in an on_load handler and store it in ordinary state attributes. A computed @rx.var that depends on those attributes will then recompute on every page load, ensuring the displayed value reflects the latest database state. A pure @rx.var that runs a query inside its body will never notice writes made by other processes unless the query touches a state attribute that changes, because the cache is keyed only on tracked attribute reads.

In practice, the hybrid approach works reliably, provided you keep the following edge cases in mind:

• Long‑lived sessions: If a user keeps a page open for hours, the on_load handler does not fire again, so the computed var will continue to display the value from the initial load. To keep data fresh during a session you need an explicit refresh mechanism (e.g., a periodic on_interval event that re‑runs the on_load logic or calls a dedicated refresh handler).
• Multi‑worker deployments: Each Reflex worker has its own per‑connection state. A refresh triggered in one worker does not propagate to clients served by another worker. If you need cross‑worker consistency, consider a shared cache (e.g., Redis) or a global state attribute that all workers can read/write.

No built‑in TTL or invalidation for computed vars

Reflex does not expose a TTL or explicit invalidation API for @rx.var. The only supported way to force a recomputation is to mutate a state attribute that the var reads. A common pattern is to maintain a last_refreshed timestamp attribute that you update whenever you fetch fresh data; the computed var then depends on that timestamp, ensuring it re‑runs whenever you update it.

Dev mode vs Production

State lifetimes and worker counts differ between reflex run (dev mode) and a production build (reflex build && reflex run --prod). Dev mode typically runs a single worker with hot‑reload enabled, so you may see stale data persist longer than in production where multiple workers serve separate connections. Always test the staleness behaviour in an environment that matches your production worker count.

Verification steps for your deployment

1. Determine the exact Reflex version:

   pip show reflex
   

2. Create a test page that uses an on_load handler to query a count from your database and store it in a state attribute row_count. Then add a computed var:

   @rx.var
   async def row_count_display(self):
       return f"Rows: {self.row_count}"
   

3. Deploy the page, load it, and record the displayed count.

4. From a separate process, insert a new row into the table.

5. Reload the page and confirm the count has increased. If it has not, the computed var is still using stale data and you need to adjust the fetch logic.

6. Repeat the test in a production‑style build (matching worker count) to ensure behaviour is consistent.

7. Optionally, add a periodic on_interval event that re‑runs the on_load logic to keep data fresh during long sessions.

Missing diagnostic detail

Could you confirm whether your production deployment uses a single Reflex worker or multiple workers? This detail can affect how state is shared across clients and may influence the staleness you observe.