Shared persistent server-side state

[lfrancke]

Epic: Shared persistent server-side state

All server-side state is held in process-local Maps, so the deployment is capped at one replica and a restart drops everything.
Part of this is already tackled in the ongoing FileBrowser PRs.

Note

This text is AI generated against our normal policy because it is migrated from another place, when we tackle this for real it needs to be properly rewritten

Four places:

• Trino connection config — src/lib/server/trino/user-clients.ts:18,
  new Map<string, UserEntry>(). Per-user URL and credentials.
• Sessions and users — src/lib/server/auth.ts. betterAuth() is called without a
  database option, so it uses the built-in memory adapter.
• Query state — src/lib/server/trino/queries.ts:76,79. Progress, rows, status and
  per-tab access times.
• Readiness — src/routes/healthz/+server.ts. Liveness and readiness both point at
  /healthz, which always returns 200.

What this costs

• replicaCount is a plain user-settable chart value (values.yaml:4, documented as
  "Number of replicas") with nothing stopping someone setting it to 2. At two replicas
  users are logged out at random, a query started on one pod is invisible to the other,
  and a saved connection only exists on the pod that received it.
• A restart orphans running queries in Trino, loses completed results, and logs everyone out.
• A readiness probe has nothing meaningful to check, so /readyz would be a placeholder
  until a backing store exists.

Scope

• Pick a backing store and wire all four consumers to it. Allow using postres as storage backend for better-auth #41 proposes PostgreSQL for
  better-auth; whatever is chosen should cover all four rather than solving them separately.
• Split /healthz (liveness, trivial) and /readyz (readiness, checks the store), and
  update the Helm probes.
• Decide what replicaCount > 1 does until then: document the constraint, or make the
  chart reject it.

Out of scope

• Persisting completed query results beyond their TTL (STACKABLE_COCKPIT_QUERY_TTL, default 1800s). Separate question.
• S3 credentials in localStorage (S3 connection credentials stored in localStorage #306). Client-side, different problem.