{"version":"2.1.248","anchor":"snapshot-failures-distinguish-momentary-races-from-real-prob","canonical_anchor":"snapshot-failures-distinguish-momentary-races-from-real-prob","heading":"Snapshot failures distinguish momentary races from real problems","tier":"notice","area":"Checkpoints","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/snapshot-failures-distinguish-momentary-races-from-real-prob","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Snapshot failures distinguish momentary races from real problems\n\nCheckpoint snapshot failures caused by files changing are now flagged as retryable races.\n\n**What**\n\nWhen a checkpoint snapshot fails because files were changing underneath it, that is now reported as a momentary failure rather than as a corrupt attributes file or an unreadable path, so a retry is the obvious response.\n\n**Details**\n\n- Three cases now produce the momentary result: staged copies changing while git read them, `.git\/info\/attributes` changing mid-read, and the staging step itself reporting momentary.\n- `momentary` is carried through as its own reason code next to `too_large`, `busy` and `too_many_paths`.\n- A file that changes while being read gets an explicit message naming that file.\n- No such classification existed in the previous build.\n\n**Evidence**\n\n`the staged copies changed while git read them`\n\n- Area: Checkpoints\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}