← Back to PRs

#16987: fix(config): add skipCache to updateSessionStoreEntry and updateLastRoute to prevent lost updates

by AI-Reviewer-QS open 2026-02-15 09:12 View on GitHub →
stale size: XS
## 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