Two instances of a code-review agent are running concurrently to handle high review volume. Both instances read the same shared state file that tracks which pull requests have been assigned for review, add their assignments to the list in memory, and then write the updated list back to the file. After several hours, the team notices that some pull requests are assigned to two reviewers while others have no reviewer, indicating state corruption. What is the root cause?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Two agents grabbing the same to-do list, each writing their additions without knowing the other is doing it at the same time — classic lost update problem. When Agent 2's write lands after Agent 1's, it overwrites Agent 1's additions entirely. The fix is distributed locking or compare-and-swap so only one writer modifies the state at a time.
Full explanation below image
![2048x1536 landscape infographic titled 'Lost Update — Concurrent Write Without Lock'. Center: timeline showing Agent A and Agent B concurrently reading state [PR 1,2,3], both adding their own PR assignments in memory, Agent A writes [1,2,3,4], Agent B writes [1,2,3,5] — overwriting Agent A's entry, PR 4 lost in red. Right panel labeled 'FIX — Three Options': Option 1: distributed lock (one agent at a time), Option 2: compare-and-swap with version check, Option 3: atomic append only (no read-modify-write). Result: both assignments preserved, no duplicates or gaps. GitHub dark palette.](/media/github/gh-600/GH-600-e3-q023-infographic.webp)
Full Explanation
The read-modify-write pattern on shared state without a lock is a classic race condition. Here is the sequence that causes corruption:
1. Agent Instance A reads the state file (PR list: [1, 2, 3]) 2. Agent Instance B reads the state file (PR list: [1, 2, 3]) — same snapshot 3. Agent A adds PR 4 and writes back (PR list: [1, 2, 3, 4]) 4. Agent B adds PR 5 to its in-memory copy and writes back (PR list: [1, 2, 3, 5]) — Agent A's addition of PR 4 is overwritten
The result is lost updates: some additions are dropped, others may be applied twice if both instances happen to add the same PR independently.
Solutions include: (1) a distributed lock (mutex) that allows only one agent to perform the read-modify-write at a time; (2) compare-and-swap (optimistic locking) where the write includes the version seen at read time and fails if the state has changed, forcing a retry; (3) moving to an atomic append operation where each agent only adds its own assignment without reading and rewriting the full list.
Option A (file format change to database) addresses the symptom but not the cause. A database does not inherently prevent the lost-update problem without isolation levels and locking configured appropriately.
Option C (time zone conflicts) is not a real failure mode for this type of state management operation.
Option D (file too large) would cause read errors or truncation, not the specific pattern of some PRs having two reviewers and others having none.