An agent that manages GitHub repository settings is designed to run on a schedule. Due to an infrastructure issue, the agent's execution is interrupted midway and it restarts automatically, re-running all steps from the beginning. Which design principle MOST effectively prevents the agent from creating duplicate issues, posting duplicate comments, or applying conflicting settings changes on the re-run?
Select an answer to reveal the explanation.
Short Explanation and Infographic
An agent that reads before it writes is like a carpenter who checks if the nail is already in before swinging the hammer. Checkpoints and exactly-once delivery solve the restart problem at the infrastructure level — idempotency solves it at the operation level, which is more robust because it works even when infrastructure guarantees fail. Read-before-write means 'already done? skip it.' That logic travels with the operation itself, not with an external coordination system.
Full explanation below image
Full Explanation
Idempotency is the property that executing an operation multiple times produces the same result as executing it once. In agent systems that perform write operations on shared state (GitHub repos, issue trackers, settings), idempotency is a fundamental correctness requirement.
Option A (global lock) prevents concurrent duplicate execution but does not help with sequential re-runs. If the agent crashes, the lock may need to be manually cleared before the agent can restart. Distributed locks also introduce their own failure modes (lock holder crashes before release, lock timeout issues). Locks prevent concurrent problems; they do not make individual operations safe to re-run.
Option B is correct and implements the read-before-write pattern: before creating an issue, check if an identical issue already exists and skip creation if it does. Before posting a comment, check if the comment was already posted. Before changing a repository setting, read the current value and skip the write if it already matches the desired value. This pattern makes each operation intrinsically safe to re-run, regardless of whether the re-run is caused by a crash, a retry, a test, or a duplicate trigger. The idempotency key lives in the operation's own logic, making it independent of external coordination systems.
Option C (checkpoint system) is a valid approach but is more complex and less robust than idempotency. Checkpoints require reliable storage for the progress state, correct implementation of resume logic, and handling of partial-completion edge cases. If the checkpoint system fails, the agent falls back to a non-idempotent re-run. Idempotent operations do not depend on checkpoint correctness.
Option D (exactly-once message queue) moves the problem to infrastructure. Truly exactly-once delivery in distributed systems is extremely difficult to guarantee and often means 'at-most-once' or 'at-least-once with deduplication.' Even with exactly-once delivery, the downstream GitHub API call may still be retried due to timeouts, making the deduplication problem resurface. Idempotency at the operation level is more robust than exactly-once delivery guarantees.