Bound and observe in-process single-flight state

[lan17]

Priority

P1 — High — resolve before broad production adoption or large-scale use.

Problem

inFlight is an unbounded map whose entries remain until the leader promise settles. A hung fallback/read can retain a key indefinitely; many unique hung keys can grow promises, closures, and request state without bound, while followers wait forever.

Evidence:

• Unbounded in-flight map
• Cleanup only after settlement

Open decision

Decide whether the first step is observability, an entry cap, follower wait budget, leader lease, or a combination. Do not silently delete active leaders and permit duplicate fallback writes without approved semantics.

Acceptance criteria

• Expose active leader count, follower count, and oldest leader age.
• Test hung leaders, rejected leaders, unique-key bursts, follower cancellation, and cleanup.
• Define how a timed-out follower differs from leader cancellation.
• Preserve absence of unhandled rejections.
• Keep process-local lifecycle work separate from cross-process coordination in Design optional cross-process cache stampede protection #7.
• Coordinate network/client time budgets with Prevent Redis outages from amplifying latency, source load, and logs #38.