Description
In src/cron/schedule.ts, the cronEvalCache uses a Map with a max size of 512 entries. When the cache is full, it evicts the first inserted entry via Map.keys().next().value.
However, cache hits via .get() do not move the entry to the end of the Map iteration order. This means frequently-accessed cron expressions that were inserted early get evicted, while rarely-used entries inserted later persist.
Code Reference
// src/cron/schedule.ts
if (cronEvalCache.size >= 512) {
const first = cronEvalCache.keys().next().value;
cronEvalCache.delete(first);
}
Map in JS preserves insertion order — .get() does NOT reorder entries. So this is FIFO eviction, not LRU.
Impact
- Frequently evaluated cron expressions (e.g.,
*/5 * * * * for heartbeats) get evicted and re-parsed unnecessarily
- Cache hit rate degrades under load when many unique expressions are registered
Suggested Fix
On cache hit, delete and re-set the entry to move it to the end of Map iteration order:
if (cronEvalCache.has(key)) {
const val = cronEvalCache.get(key);
cronEvalCache.delete(key);
cronEvalCache.set(key, val);
return val;
}
This gives true LRU behavior with zero additional dependencies.
Description
In
src/cron/schedule.ts, thecronEvalCacheuses aMapwith a max size of 512 entries. When the cache is full, it evicts the first inserted entry viaMap.keys().next().value.However, cache hits via
.get()do not move the entry to the end of the Map iteration order. This means frequently-accessed cron expressions that were inserted early get evicted, while rarely-used entries inserted later persist.Code Reference
Mapin JS preserves insertion order —.get()does NOT reorder entries. So this is FIFO eviction, not LRU.Impact
*/5 * * * *for heartbeats) get evicted and re-parsed unnecessarilySuggested Fix
On cache hit, delete and re-set the entry to move it to the end of Map iteration order:
This gives true LRU behavior with zero additional dependencies.