Greptile Summary

This PR bundles three distinct changes under the cron LRU cache fix title: (1) the stated LRU fix in schedule.ts, (2) a new isTransientSqliteError handler in unhandled-rejections.ts, and (3) enabling WAL journal mode in manager-sync-ops.ts.

• src/cron/schedule.ts — The LRU fix is correct. Delete-then-re-insert on a cache hit moves the entry to the tail of Map iteration order, ensuring the eviction path always removes the least-recently-used entry.
• src/infra/unhandled-rejections.ts — SQLITE_BUSY and SQLITE_LOCKED are legitimately transient, but SQLITE_CANTOPEN (missing file / bad permissions that won't self-heal) and SQLITE_IOERR (a broad parent code covering disk-level failures) are not reliably transient. Treating them as such means the gateway can silently continue running while its database is inaccessible, masking data-loss or corruption rather than crashing fast. The message-matching path also skips the case-normalization (.toUpperCase()) used by the analogous network-error checker, leaving lowercase variants undetected.
• src/memory/manager-sync-ops.ts — WAL mode is a good addition; it is idempotent and improves crash-safety. The return value of the pragma is not checked, so a silent fallback on unsupported filesystems would go unnoticed, but this is a low-impact edge case.

Confidence Score: 2/5

• The SQLite transient-error classification in unhandled-rejections.ts can cause the gateway to silently continue after non-recoverable database failures; needs tightening before merge.
• The cron LRU fix and WAL mode change are both correct and safe. However, classifying SQLITE_CANTOPEN and SQLITE_IOERR as transient in the unhandled-rejection handler is a meaningful logic issue: these codes often represent permanent conditions, and suppressing them turns a crash-fast failure into a silent, hard-to-diagnose broken state. This lowers confidence significantly.
• src/infra/unhandled-rejections.ts — specifically the TRANSIENT_SQLITE_CODES set and the isTransientSqliteError message-matching logic.

_{Last reviewed commit: 0a9c952}

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

Closing this as duplicate or superseded after Codex automated review.

Close as superseded by #39703. The cron LRU behavior is still not implemented on current main, but #39703 already tracks the same remaining fix as a narrower PR with regression-test coverage, while #39706 bundles unrelated SQLite/WAL changes that were flagged in review and have since diverged on main.

Best possible solution:

Close #39706 as superseded by #39703 and keep the remaining cron LRU work on that focused PR or an equivalent narrow branch. The eventual fix should promote cache hits before eviction and include a regression test that proves hot cron entries remain cached after capacity eviction.

What I checked:

• Current main still has FIFO cron eviction: At HEAD 73e2151, resolveCachedCron() returns a cached Cron immediately without deleting/re-setting the key, then evicts cronEvalCache.keys().next().value when full. That is insertion-order FIFO behavior, not true LRU. (src/cron/schedule.ts:17, 73e21511075d)
• Current cron tests do not cover eviction order: The existing cron cache test verifies reuse and final cache size for repeated expression/timezone lookups, but it does not fill the cache, promote a hot key, or assert which key survives eviction. (src/cron/schedule.test.ts:127, 73e21511075d)
• Canonical related PR tracks the same remaining work: The provided/local ClawSweeper report for fix: use LRU eviction for cron schedule cache instead of FIFO #39703 shows it is an open PR titled “fix: use LRU eviction for cron schedule cache instead of FIFO”; it was kept open because current main still has FIFO eviction, and its branch is focused on the cron cache with a key-level regression test asserting promoted entries survive eviction. (src/cron/schedule.test.ts:145, 00cb426b2c66)
• This PR is dirty relative to the focused cron fix: The provided PR context shows fix(cron): implement true LRU cache eviction #39706 changes src/cron/schedule.ts plus unrelated SQLite transient-error handling and WAL-mode code. Review comments flagged those unrelated SQLite/WAL changes, and current main now has a different SQLite handler/WAL layout, including src/infra/unhandled-rejections.ts and WAL setup under src/tasks and src/proxy-capture rather than the old src/memory/manager-sync-ops.ts path. (src/infra/unhandled-rejections.ts:70, 73e21511075d)

So I’m closing this here and keeping the remaining discussion on the canonical linked item.

Codex Review notes: model gpt-5.5, reasoning high; reviewed against 73e21511075d.