For many calamities that might befall an action, QRecall will automatically repair the archive when the next action is performed. When this happens, all the work of the previous action is undone—as if it had never run.
Auto-repair is the first step performed by every action or command (with the possible exception of the repair command).
Debacles that might interrupt an action include:
Following a failure of this kind, the first step you should do is nothing; let the next action run and see if auto-repair can fix the archive. If you don't want to wait, run a verify action which will first—yes, you guessed it—perform an auto-repair. If auto-repair is possible, the next action will run successfully and no further action needs to be taken.
If auto-repair is not successful, you will need to repair the archive. If you'd like that to happen automatically, create a repair action and schedule it to run whenever the archive needs repair.
Most actions¹ that modify the contents of an archive begin by making backup copies of key index information.
If the action is violently interrupted, this preserved information is used to by the next action to "roll back" the archive to the state it was in before the interrupted action started.
¹The notable exception is the compact action. On non-APFS volumes, it is the one action that makes changes that can't be undone. If a compact action is prevented from properly closing the archive, it will need to be repaired.
Auto-repair thinks differently on APFS.
QRecall exploits the "file cloning" feature of the APFS filesystem to make lightweight copies of every file in the archive it intends to modify. This is much faster than making a physical copy of the files, and it occupies no additional space on the volume.
Actions start running faster and it's possible for auto-repair to restore an archive on an APFS volume in almost all situations—even the compact action.
This does come at a cost. Repeatedly cloning and modify a file can create extreme file fragmentation. If this goes on long enough, file performance will be degrade significantly.
To address this, QRecall monitors the fragmentation of archive files on APFS volumes. If the fragmentation become too severe, it will perform a proprietary "defragmenting" procedure at the end of an action. This phrase runs incrementally with the intent of keeping file fragmentation to a reasonable level.