#16987: fix(config): add skipCache to updateSessionStoreEntry and updateLastRoute to prevent lost updates
stale
size: XS
Cluster:
Session Lock Improvements
## Summary
- `updateSessionStoreEntry` and `updateLastRoute` both call `loadSessionStore` inside `withSessionStoreLock` but were missing `{ skipCache: true }`, unlike the sibling function `updateSessionStore` which correctly passes it
- Without `skipCache`, the second writer inside the lock could re-read a cached (pre-write) snapshot, causing a lost-update race where the first writer's changes are silently clobbered
- Added `{ skipCache: true }` to both call sites, matching the existing pattern and comment in `updateSessionStore`
## Test plan
- Existing test `concurrent updateSessionStoreEntry patches all merge correctly` in `store.lock.test.ts` validates that concurrent patches merge without data loss
- Verified the fix matches the established pattern at `store.ts:597` (`updateSessionStore`)
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
Adds `{ skipCache: true }` to `loadSessionStore` calls inside `updateSessionStoreEntry` and `updateLastRoute`, matching the existing pattern in `updateSessionStore`. Without this, the in-memory TTL cache could serve a stale snapshot to the second writer inside `withSessionStoreLock`, causing a lost-update race where the first writer's changes are silently overwritten.
- Added `{ skipCache: true }` to `loadSessionStore` in `updateSessionStoreEntry` (line 768)
- Added `{ skipCache: true }` to `loadSessionStore` in `updateLastRoute` (line 831)
- Both changes align with the established pattern at `updateSessionStore` (line 597)
- All `loadSessionStore` calls inside `withSessionStoreLock` now consistently bypass the cache
<h3>Confidence Score: 5/5</h3>
- This PR is safe to merge — it fixes a real concurrency bug with a minimal, well-established pattern.
- The change is a two-line fix that adds `{ skipCache: true }` to two `loadSessionStore` calls inside locked read-modify-write sections, matching the existing correct pattern in `updateSessionStore`. The fix is consistent, minimal, and addresses a genuine lost-update race condition. All `loadSessionStore` calls inside `withSessionStoreLock` now correctly bypass the cache. Existing tests validate the concurrent merge behavior.
- No files require special attention
<sub>Last reviewed commit: e349cdf</sub>
<!-- greptile_other_comments_section -->
<!-- /greptile_comment -->
Most Similar PRs
#10726: fix: re-read session store inside lock in updateLastRoute
by Yida-Dev · 2026-02-06
90.8%
#10725: fix: re-read session store inside lock in updateSessionStoreEntry
by Yida-Dev · 2026-02-06
90.6%
#16609: fix: resolve session store race condition and contextTokens updates
by battman21 · 2026-02-14
79.5%
#15882: fix: move session entry computation inside store lock to prevent ra...
by cloorus · 2026-02-14
78.1%
#4664: fix: per-session metadata files to eliminate lock contention
by tsukhani · 2026-01-30
76.4%
#16542: fix(sessions): use atomic temp+rename write on Windows
by aldoeliacim · 2026-02-14
76.1%
#19328: Fix: preserve modelOverride in agent handler (#5369)
by CodeReclaimers · 2026-02-17
75.8%
#20188: fix: Update sessionFile path when rolling to new session in cron jobs
by jriff · 2026-02-18
75.7%
#15945: fix(memory-flush): only write memoryFlushCompactionCount when compa...
by aldoeliacim · 2026-02-14
75.5%
#20770: fix: prevent stale session-entry overwrite during reset-model persi...
by coygeek · 2026-02-19
75.1%