Fence in-process single-flight work across invalidation boundaries

[lan17]

Priority

Closed — accepted overlap semantics; no generation or cancellation machinery planned.

Problem

A caller that starts after invalidateRemote(keyType, id) resolves can still join an exact-key fallback that began before invalidation and directly receive its result, even if Redis rejects the eventual stale write.

Confirmed decision — tolerate overlapping in-flight work

DialCache invalidation fences cache publication; it does not cancel, split, or version application fallback work that is already running.

• An unfinished fallback Promise may still be shared with a same-instance, exact-key caller that arrives after invalidation but before that shared promise settles.
• For enabled fallbacks, feat: add fallback deadlines and coalescing state #69 now applies a 60,000 ms deadline by default, supports a positive per-wrapper fallbackTimeoutMs, and allows explicit null opt-out. Timeout rejects the shared DialCache promise and prevents late publication, but does not cancel the underlying source operation.
• Configuration-provider, ramp-sampler, Redis, and serializer work remains caller-budgeted and can precede or follow the bounded fallback phase.
• The Redis watermark and application-sized futureBufferMs protect against stale tracked Redis and corresponding process-local publication; they do not retract a result already being computed for callers.
• No local generation map, cancellation protocol, public invalidation API, Redis protocol, or key-format change will be added for this case.
• Applications requiring strict read-after-invalidation response ordering must coordinate that stronger guarantee at the application boundary.
• Cross-process stampede coordination remains separate in Design optional cross-process cache stampede protection #7.

Closure rationale

The effect is limited to overlapping calls for the same exact key and cache instance. The default fallback deadline now bounds the shared fallback phase unless explicitly disabled, while the accepted consistency model still avoids generation/cancellation complexity. This issue remains closed as not planned.