You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
P3 — Low — the stale-publication safety property is already enforced; remaining work is focused operational documentation and edge-case coverage.
v0.14.0 grooming verification (2026-08-01)
The fail-closed watermark behavior and explicit-invalidation repair path remain intact on main@34bd022. The remaining work is limited to the repair runbook plus concurrent and persistent-malformed coverage; no new repair API, background subsystem, or automatic mutation is justified. This is a candidate for not planned closure if those out-of-contract corruption cases do not merit dedicated work, but no closure decision is recorded here.
Current behavior at v0.10.0
Malformed or overflowed tracked watermarks fail safely:
Tracked reads treat them as misses.
Tracked writes reject without replacing the cached value.
DialCache returns the source fallback and suppresses tracked process-local publication.
Explicit invalidateRemote() atomically replaces malformed or overflowed contents with a fresh Redis-time watermark.
A valid persistent watermark remains persistent after invalidation.
The remaining failure mode is availability/load, not stale value publication: a corrupt watermark forces repeated fallbacks and tracked-write errors until it expires or is explicitly invalidated.
Remaining scope
Document the operational repair sequence: commit the source mutation, then call invalidateRemote(keyType, id, the application's normal safety buffer).
Add concurrent repair coverage.
Add a persistent-malformed repair case.
State that applications should give DialCache exclusive ownership of its namespace/key format.
Decision required before implementation
Recommended simplicity-first direction: retain fail-closed reads/writes and use explicit invalidateRemote() as the sole repair path. Do not add automatic repair, a background subsystem, another public API, or a dedicated metric unless production evidence shows the existing bounded cache_write signal and logger are insufficient.
Acceptance criteria
No corrupt watermark can make an older cached value valid.
Ordinary reads/writes remain fail closed.
Explicit invalidation repairs malformed and overflowed contents atomically under concurrency.
Persistent malformed and valid-persistent behavior is documented and tested.
Recovery instructions preserve the source-commit and futureBufferMs ordering contract.
Close after the focused tests and documentation land.
Priority
P3 — Low — the stale-publication safety property is already enforced; remaining work is focused operational documentation and edge-case coverage.
v0.14.0 grooming verification (2026-08-01)
The fail-closed watermark behavior and explicit-invalidation repair path remain intact on main@
34bd022. The remaining work is limited to the repair runbook plus concurrent and persistent-malformed coverage; no new repair API, background subsystem, or automatic mutation is justified. This is a candidate for not planned closure if those out-of-contract corruption cases do not merit dedicated work, but no closure decision is recorded here.Current behavior at v0.10.0
Malformed or overflowed tracked watermarks fail safely:
invalidateRemote()atomically replaces malformed or overflowed contents with a fresh Redis-time watermark.Current evidence:
DialCache/src/internal/redis-scripts.ts
Lines 57 to 115 in 84341f2
DialCache/src/internal/redis-scripts.ts
Lines 117 to 156 in 84341f2
DialCache/test/redis-real.integration.test.ts
Lines 437 to 477 in 84341f2
DialCache/test/redis-real.integration.test.ts
Lines 566 to 605 in 84341f2
The remaining failure mode is availability/load, not stale value publication: a corrupt watermark forces repeated fallbacks and tracked-write errors until it expires or is explicitly invalidated.
Remaining scope
invalidateRemote(keyType, id, the application's normal safety buffer).Decision required before implementation
Recommended simplicity-first direction: retain fail-closed reads/writes and use explicit
invalidateRemote()as the sole repair path. Do not add automatic repair, a background subsystem, another public API, or a dedicated metric unless production evidence shows the existing boundedcache_writesignal and logger are insufficient.Acceptance criteria
futureBufferMsordering contract.