1. Lock in the situation before clicking rerun
Stop adding work and check that no run of the same batch is still active. A lost connection doesn't always mean the software has stopped. Check its state when possible: launching a second copy can create duplicates or write to the same destinations.
Keep the log, the list of input files, the settings, and the error message. Make a copy of the tracking table before correcting it. Keep questionable outputs in a separate location, without overwriting the originals or results that have already been accepted. If the destination is full, make room or prepare another destination after identifying what must be kept.
2. Give each item a stable identity
One line should represent one expected task, for example IMG-017 associated with catalogue/chaise-face.png. The path alone can become ambiguous after a move; a short name like photo.png can exist in several folders. Keep a unique identifier and the match with the original input.
Add the configuration identifier, the output path, the status, the attempt number, and a short reason. This log can be an ordinary table or a CSV from your project. It doesn't need to contain the images, passwords, or the machine's entire technical log. A person should be able to find the right entry and explain why it appears in the resume.
Do not modify the original behind an identifier that has already been accepted. A new entry or a different transformation requires a new version that is clearly noted. Otherwise, the same identifier would end up referring to two incompatible jobs and the log would no longer let you decide what is finished.
| ID | Configuration | Status | Output or reason |
|---|---|---|---|
| IMG-017 | essai-02 | Accepted | IMG-017.png opened and checked |
| IMG-018 | essai-02 | To verify | File present, check not finished |
| IMG-019 | essai-02 | Failed | Out of memory during processing |
| IMG-020 | essai-02 | To do | No expected output found |
3. Reconcile the log with the actual files
For each planned identifier, look for the expected output. Check the format, dimensions, or content needed for your use, then open the file with the destination tool. Outputs that have already been accepted and are still present stay off the resume list. If an output is missing while the log says "accepted," first look for a saved copy before deciding to recompute it.
Classify the items that were "in progress" at the time of the stop among those to verify. Some may be complete, others only partial. The date or file size is a clue, not a validation. An extra file with no known identifier stays aside until you trace where it came from.
For images, Pillow distinguishes identifying the file, reading its pixels, and verifying its structure. So a program that merely opens its header doesn't check everything. An automated check can detect certain corruptions; it doesn't judge whether the text is legible or whether the colors match the deliverable.
4. Separate an incomplete item from a rejected result
A partial output must be redone or restored from a complete copy. A complete but unacceptable output first requires understanding the defect. Rerunning the same settings on an unreadable input or on a case that consistently runs out of memory will probably repeat the problem. Note the fix before putting that identifier back in the queue.
Keep the number of statuses small: to do, in progress, to verify, accepted, and failed. Moving to "accepted" comes after the check, not when the computation starts. If you decide to exclude an item, add a "discarded" status with a reason and the approval relevant to the project. It must not silently disappear from the expected total.
Don't count a new attempt as a new task. IMG-019 can have three attempts and only one accepted output. This distinction avoids confusing sixty runs with sixty different deliverables.
Example: finding the nineteen items still needed
This illustrative scenario involves sixty independent images. After an interruption and a check, forty-one outputs are accepted, four are partial, six failed, and nine are missing. The log does cover 41 + 4 + 6 + 9 = 60 identifiers. The resume concerns nineteen items, provided the causes of the six failures are addressed.
The responsible person reconstructs a list of nineteen identifiers, then distinguishes the four partial files, the six errors, and the nine tasks without output. They take up a corrected entry and a missing entry first. They also confirm that an image already accepted does not appear in the selection. This small check validates the list before the remaining processing.
If eighteen additional items are then accepted and one source file remains unreadable, the tally is fifty-nine accepted and one explained failure. The batch is not declared complete at sixty. The next choice is to find a correct entry again or to get its exclusion approved, not to hide the line.
| Status after check | Number of identifiers | Proposed action |
|---|---|---|
| Accepted and output found again | 41 | Keep; no rerun |
| Partial output | 4 | Set aside, then redo |
| Identified failure | 6 | Fix the cause before retrying |
| Missing output | 9 | Take up again from the entry |
| Total to redo | 19 | 4 + 6 + 9, without duplicates |
5. Produce the rerun in a separate location
Prepare a rerun folder with only the retained identifiers, or use your software's explicit selection. Review the list before launching. If the tool offers "skip existing files," check what that means: the existence of a partial file may cause it to be skipped by mistake. The verified log remains your reference.
Have the new outputs produced in a separate folder, along with their configuration and their attempt. Validate them before replacing a previous version. Some scripts can overwrite an existing file without asking for confirmation; Python documents this in particular for os.replace. A naming convention alone does not protect against replacement.
If the settings change to fix a defect, keep that change visible. You can keep outputs from two configurations if they meet the same criteria and if the mix is acceptable for the project. For a visually consistent series, also compare the new outputs with the old ones before merging the folders.
6. Verify the tally by identifier, not just by quantity
At the end, every expected identifier must have an explained status. Two copies of IMG-017 do not make up for the absence of IMG-020. Check that names are unique, that they match the entries, and the configuration of the retained outputs. Open the redone files and check the points that prompted their rerun.
The completed folder includes the accepted outputs, the updated log, the settings, and the list of any items set aside or still blocked. Back up this set with a verified copy. An "accepted" line does not replace the file or its backup.
This method takes up independent tasks from their input. It does not allow you to automatically continue a simulation, a render, or a training run from the exact instruction where it stopped. Such work requires a resume state specific to the software. Also, do not assume that a folder left on a rented environment will be kept after the period: prepare your copy.