You are configuring an agent that uses an MCP tool to apply automated code fixes across 100 repositories. The agent crashed at repository 47. You want to restart it so it resumes at repository 48 and applies exactly the same fix strategy decided in earlier runs. Which implementation correctly achieves this?
Select an answer to reveal the explanation.
Short Explanation
You don't restart from scratch after a crash. You read the checkpoint, load the completed repos and recorded fix decisions, then call the MCP tool at repository 48 with the same strategy. That gives clean resumption without drift or repeat.
Full Explanation
Safe resumption from a checkpoint requires two things: knowing where to resume (progress tracking) and what decisions to carry forward (decision log). Both must be explicitly encoded in the checkpoint artifact and explicitly loaded at resume time.
Why the checkpoint-loading approach is correct: Reading the checkpoint artifact on startup provides: 1. The list of completed repositories (1-46), so the agent skips them entirely. 2. The fix strategy decisions (such as one approach for Python repos and another for TypeScript repos) that were already established, ensuring the resumed run doesn't diverge from the prior run's decisions. 3. The exact starting point (repository 48), so the MCP tool is invoked from the correct position. This is the complete, correct resumption pattern.
Why re-deriving the fix strategy from the original prompt is wrong: Re-deriving the fix strategy from the original prompt is non-deterministic. Language models may produce a slightly different strategy when given the same prompt on a different run, especially if temperature > 0 or if the model version has changed. This introduces decision drift — the resumed run may apply different fixes than the original run intended, violating the 'resume without diverging from prior decisions' requirement.
Why re-running all 100 repositories with idempotent fix operations is wrong: While idempotency is a useful property for robustness, re-running all 100 repositories wastes time and compute on 46 already-completed repositories. For operations with side effects (such as PR creation, notification triggers, API calls), even idempotent operations may create noise (duplicate PRs later de-duped, etc.). The goal is clean resumption, not brute-force replay.
Why restarting at repository 47 and relying on version control history is wrong: Relying on version control history to detect skippable work is fragile. It assumes all prior changes were committed and pushed, that the commit messages or diff content are parseable by the agent to determine 'already applied', and that no concurrent changes have been made. It also doesn't address the fix strategy — VCS history alone doesn't tell the agent which decisions were made for repositories not yet started.