Shared storage, deployment ids and instrumentation

A page cache, data cache, session store or rate limiter that must be shared by several server instances needs a store they all reach. Dusk's stores are built on the KVStore interface: createMemoryKVStore is per process, createFileKVStore (in @shadow-js/dusk/node) is one file per key for one server, and the adapters (createKvCacheStore, createKvSessionStore, createKvRateLimitStore) accept any implementation of KVStore. Pass the store to createHandler({ cache: { kv } }), and to the session manager and the rate limiter as their store. For the page cache over a Redis client, cache: { store: redisStore(client) } from @shadow-js/dusk/stores/redis is the shared store (see Scaling the caches for the adapters and their sharing and atomicity requirements). The adapters serialize their own read-modify-write steps inside one process; across processes the store must provide the atomicity itself.

Each build has a deployment id (see the configuration guide). Rolling a deploy one instance at a time is safe: a browser that calls an instance of another build gets 409 DEPLOYMENT_MISMATCH and reloads.

src/instrumentation.ts runs register() once when the server starts, and onRequestError for every error the framework reports. Its tracer takes the OpenTelemetry tracer shape, so an OpenTelemetry tracer can be passed without a Dusk dependency on it. A failing hook is logged; it never fails a request or stops the process.