Enforce runtime-configurable remote read deadlines and fail open without a second Redis operation #38

Priority

P1 — High — completed.

Resolution

Completed by #83 (a9a28042cb81ea72e9adb23834d86b7882b9815a) and released in https://github.com/lan17/DialCache/releases/tag/v0.10.0.

Shipped contract

• Every active remote read has a finite core wait deadline.
• The library default is 50 ms.
• RedisConfig.readTimeoutMs optionally sets an instance default.
• DialCacheKeyConfig.remoteReadTimeoutMs participates in the existing static/runtime per-use-case overlay.
• Precedence is runtime overlay, operation defaultConfig, instance redis.readTimeoutMs, then 50 ms.
• Values must be positive safe integers no greater than 2,147,483,647; there is no unbounded escape hatch.
• cached() and getOrLoad() use identical semantics.

Failure behavior

• One monotonic deadline is allocated per shared Redis-read leader; followers share it.
• The optional adapter signal is aborted on timeout, but DialCache does not claim that an already dispatched command was canceled.
• A timeout or read exception starts the source loader and skips the post-loader Redis write, avoiding a second operation against an unhealthy Redis client.
• Untracked keys may safely populate an active process-local miss; tracked keys suppress local publication because watermark safety was not established.
• Late read settlement is consumed and cannot publish, suppress the loader, duplicate observability, or create an unhandled rejection.
• A later invocation starts a fresh read and can recover naturally.

Observability and adapters

• RedisReadTimeoutError exposes stable useCase and timeoutMs fields without raw cache keys.
• Timeouts use the existing bounded error metric with error="cache_read_timeout"; other read failures remain cache_read.
• The semantic client accepts optional RedisReadContext { timeoutMs, signal } without breaking existing one-argument custom clients.
• node-redis receives the cooperative signal; Valkey GLIDE retains its client-owned native request timeout.

Underlying Redis connection/retry/queue resource lifetime, writes, invalidation, serializers, and dynamic config-provider settlement remain caller-owned.