kibertoad / layered-loader / 28654852281

98%

push

github

Add optional staleness checker for conditional cache refresh (#416)

* Add optional staleness checker for conditional cache refresh

When a cached entry enters the ttlLeftBeforeRefreshInMsecs window, a new
opt-in isEntryStillCurrentFn lets the loader run a lightweight freshness
check (e.g. comparing updatedAt/version) instead of unconditionally
refetching from the data sources. If the entry is still current, its TTL
is reset to the full ttlInMsecs in both the async and in-memory layers
via new optional resetTtl/resetTtlFromGroup cache methods (Redis PEXPIRE);
otherwise, or when the check throws or the entry vanished meanwhile, the
existing full background refresh runs as before.

Supported by both Loader and GroupLoader. No storage format change; the
check receives the cached value itself. Check errors are routed to
loadErrorHandler and treated as stale, ttl bump failures to
cacheUpdateErrorHandler, so the worst case degrades to today's behavior.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ux9azWit8MhWuKcFrYx7q7

* Address staleness-checker review findings

- GroupLoader: propagate the freshly refetched value into the in-memory
  group cache on the stale/refetch path, matching the flat Loader. A
  two-layer GroupLoader no longer serves the stale in-memory value for a
  full ttl window after a conditional-refresh refetch.
- Loader/GroupLoader: fail fast at construction when isEntryStillCurrentFn
  is set on an asyncCache without ttlLeftBeforeRefreshInMsecs, instead of
  silently no-opping (the check only runs inside the refresh window).
- Loader/GroupLoader: drop the redundant in-memory set on the ttl-bump
  path. getAsyncOnly already re-set the same value when the read resolved,
  and the extra write could clobber a concurrent update with a stale snapshot.
- Deduplicate the staleness-config validation into a shared
  assertStalenessCheckSupported helper on AbstractCache.

* Address staleness... (continued)

384 of 400 branches covered (96.0%)

Branch coverage included in aggregate %.

60 of 60 new or added lines in 5 files covered. (100.0%)

700 of 700 relevant lines covered (100.0%)

122.68 hits per line