kibertoad / layered-loader / 28715985926

98%

push

github

feat: support isEntryStillCurrentFn on in-memory-only loaders (#420)

* feat: support isEntryStillCurrentFn on in-memory-only loaders

The staleness probe was hard-gated on an async cache tier: it only fired in
Loader/GroupLoader's async-hit branch and bumped freshness via
asyncCache.resetTtl/resetTtlFromGroup, so an in-memory-only loader in the
refresh window always paid a full data-source reload even when a cheap probe
could prove the cached value still current.

Make the existing pair of inMemoryCache.ttlLeftBeforeRefreshInMsecs and
isEntryStillCurrentFn a supported combination:

- Relax assertStalenessCheckSupported to accept a probe when either the async
  cache has a refresh window (+ resetTtl, unchanged) or the in-memory cache has
  a refresh window.
- Route the in-memory refresh-ahead through the probe via a new overridable
  scheduleInMemoryRefresh seam on the abstract caches; the loaders run the probe
  against the in-memory value and bump its TTL when current, falling back to the
  full background reload otherwise.
- Add resetTtl/resetTtlFromGroup to the in-memory caches (and NoopCache) plus
  the SynchronousCache/SynchronousGroupCache interfaces.
- Reuse the existing isKeyRefreshing / groupRefreshFlags stampede guards.

Precedence is unchanged: when an async cache has a refresh window it keeps
owning the probe, so existing configurations behave identically. Non-breaking.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PYBYKbY1BJD9HFM1fXtFqW

* fix: fence the in-memory staleness fallback reload through getAsyncOnlyResolved

The new in-memory refresh path issued its stale-fallback reload via a raw
loadFromLoaders + inMemoryCache.set/setForGroup, outside the runningLoads /
groupLoads registry. That bypassed the invalidation fence and dedup that the
blind refresh path relies on, so:

- an entry invalidated (invalidateCacheFor) while the fallback reload was in
  flight got resurrected af... (continued)

437 of 458 branches covered (95.41%)

Branch coverage included in aggregate %.

61 of 61 new or added lines in 7 files covered. (100.0%)

797 of 797 relevant lines covered (100.0%)

118.55 hits per line