Skip to content

Decide How a Signal-Killed Repair Run Affects DeleteInvalidFiles #1095

Closed

Description

@ptr727

Behavior

A signal-ended FfMpeg verify run is recorded in ToolErrorScope.SignalCount, so DeleteFailedFile() keeps the file and a failed repair leaves its state unchanged. The repair runs themselves are not covered. FfMpegTool.ConvertToMkv(), the FfMpeg re-encode, and HandBrakeTool.ConvertToMkv() run with CommandResultValidation.None, so a run killed by a signal reports as executed with a non-zero exit, and the repair tier just fails.

  1. A verify finds a genuine decode error, for example FFmpeg exit 183 for invalid data.
  2. The remux tier fails, then the FfMpeg re-encode is killed by a signal, for example by the out-of-memory killer during a long encode, and HandBrake fails or is killed too.
  3. VerifyAndRepair() sets VerifyFailed and RepairFailed, and with DeleteInvalidFiles on, DeleteFailedFile() deletes the file, although the repair never ran to a result.

This predates the change for #1090, which covers only the verify run. CodeRabbit raised it on #1093.

Reproduction shape

  1. Set Verify: true, AutoRepair: true and DeleteInvalidFiles: true.
  2. Process a file whose verify reports a decode error, and kill the FfMpeg re-encode with SIGKILL while it runs.
  3. The file ends VerifyFailed and RepairFailed, and it is deleted.

The decision

  1. Treat a signal-ended repair run as a tool that did not run. Record it in ToolErrorScope.Count, so the failed repair leaves the state unchanged and the file is kept, and the next run repairs again. A repair that crashes on the same input every time re-runs on every run.
  2. Treat it like the signal-ended verify. Record it in SignalCount, which keeps the file and also leaves the state unchanged, the same outcome as choice 1 through the Decide How a Signal-Terminated FfMpeg Verify Run Is Classified #1090 path.
  3. Keep the current behavior. The verify already judged the media corrupt, so a killed repair still ends in a delete.

Choices 1 and 2 differ only in which count carries it. The question is whether a killed repair should block the delete at all.

Activity

  1. added
    decisionA question waiting on the maintainer, alone or beside whatever else the issue carries
    pre-existingReview finding classed pre-existing per local-strict-review Disposing of Findings
    on Oct 30, 2026
  2. ptr727 commented on Oct 30, 2026

    @ptr727
    OwnerAuthor

    Decision: count a signal-killed repair run as a tool that did not run. Record it in ToolErrorScope.Count, so the failed repair leaves the state unchanged, the file is kept, and the next run repairs again. This is choice 1. It matches how a launch failure is treated, and the accepted cost is that a repair that crashes on the same input re-runs on every run. It is now an ordinary fix.

  3. removed
    decisionA question waiting on the maintainer, alone or beside whatever else the issue carries
    on Oct 30, 2026
  4. added a commit that references this issue on Oct 30, 2026
    b2db73c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    pre-existingReview finding classed pre-existing per local-strict-review Disposing of Findings

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions