james.maesandCodex
95ac6e6ea1
Use the Redis QBit public API with explicit namespace and lifecycle ownership. Preserve optional Redis absence and legacy providers. Local verification: 67 unit and 29 integration tests; launcher lifecycle and real HTTP outage/logout retry acceptance passed. Coordinated prerequisite publication and cold-host checks remain pending. Co-Authored-By: Codex <noreply@openai.com>
1.9 KiB
Application-scoped session store registration
The candidate core registry resolves the QInstance in QContext. Application startup must register explicitly, even when no request context exists:
QSessionStoreRegistry.getInstance(qInstance).register(provider);
Calls to getInstance() within a request use that request's application. Without
a QInstance, that call accesses a separate standalone registry. An application
never inherits that standalone provider. Existing hosts that register outside
QContext must migrate to the explicit overload alongside this core candidate.
Deploy matching session-store/core versions; this is not a transparent change for
old context-free startup integrations.
Session-store's producer now supplies its target QInstance to both core registration and qbit context. Context getters/setters/clear operate on the current application, with explicit QInstance overloads for metadata production/background operations. Health metadata selects its target application and the health probe uses the QInstance in HealthCheckInput (falling back to current context only if omitted).
Regression reproduced before the fix: after application A stored a session, unconfigured application B loaded that same session through QSessionStoreHelper. The test now checks independent same-ID sessions, isolation of clearing, and health checks for an explicit target while a different application is on the caller thread.
Hosts sharing a Redis server must configure separate application/authentication
domain namespaces. The SHARED_REDIS provider uses those explicit settings and
the owning Redis QBit's pool. Its runtime releases owned registrations on stop
and reconstructs them on restart. Local acceptance covers launcher lifecycle,
HTTP authentication/logout and Redis outage/retry; coordinated published-artifact
and clean-host verification remain release gates. See the shared Redis setup in
README.