Checkpoint snapshot failures caused by files changing are now flagged as retryable races.
What's wrong with this entry?
When 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.
- Three cases now produce the momentary result: staged copies changing while git read them,
.git/info/attributeschanging mid-read, and the staging step itself reporting momentary. momentaryis carried through as its own reason code next totoo_large,busyandtoo_many_paths.- A file that changes while being read gets an explicit message naming that file.
- No such classification existed in the previous build.
the staged copies changed while git read them
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.233
Checkpoint notice now tells you how to undo the turn
Both mention checkpoint
-
v2.1.233
Resume checkpoint file now tells you how to undo the turn
Both mention checkpoint