Would you accept a pluggable non-Redis store backend?

[agjmills]

Asking before writing anything, because the answer changes whether it is worth starting.

Where we are

We run ShinyProxy per tenant on Kubernetes, one deployment each, on 3.2.4. Every tenant
already runs MongoDB for its own application data and its authenticator's sessions. Redis
is in the estate for exactly one reason: proxy.store-mode: Redis, so that a restart does
not log everyone out.

Concretely, without it a pod restart loses the in-flight authorization request and the
login fails with authorization_request_not_found. We reproduced that deliberately —
callback with the session cookie gives invalid_grant, callback without it gives
authorization_request_not_found — and confirmed Redis fixes it: after switching, the same
test across a full pod replacement now reaches invalid_grant, i.e. the new pod finds the
request the old one saved.

So Redis works and nothing is broken. The question is only whether a second datastore has
to exist per tenant to get that.

What makes this a containerproxy question

The obvious framing is "use Spring Session with the Mongo backend", and that half looks
straightforward — Spring Session already ships one.

The half that is not is the proxy store itself, and it lives here rather than in
shinyproxy. From our own logs on a Redis-backed instance:

e.o.c.s.l.r.RedisCheckLatestConfigService : No proxy.version property found, assuming ...
e.o.c.s.leader.redis.RedisLeaderService   : This server (runtimeId: ...) is now the leader.
e.o.c.b.d.p.ProxySharingScaler            : [specId=risks ...] Started DelegateProxy

So store-mode: Redis is not only session persistence — it is leader election, the
config-version check, and seat/port allocation for app sharing. That last one is presumably
why Redis store does not support allocating existing ports exists as a distinct error.
Those are the parts built on Redis primitives, and reimplementing them on a document store
means reproducing distributed leader election and atomic seat allocation with different
guarantees. That is the risk, and it is the part worth agreeing on before anyone writes it.

What we are actually asking

1. Is a second store backend something you would consider taking at all, or is Redis a
   deliberate single-implementation choice we should stop pushing against?
2. If you would consider it, is the store boundary somewhere you regard as an extension
   point, or is it internal and expected to change?
3. If the answer to (1) is yes, would you want leader election kept on a separate
   mechanism rather than reimplemented per backend? Splitting it out looks like it would
   shrink the surface a good deal, and might be a useful change on its own.

We are offering to do the work, not asking for it. But we would rather find out now that
you do not want a second backend than arrive with a large PR against an interface you were
planning to change.

What would settle it

A yes/no on (1) is enough to act on. If it is no, we will keep running Redis and stop
thinking about it — that is a perfectly reasonable answer and worth saying plainly.