A failed file mutation records that it failed and discards why. I went looking for the cause of a real import failure, could not find one, and the reason turned out to be that the information is thrown away in three places on the way out.
Checked against canary a630572e (1.3.4).
Where the detail goes
FileMover.PerformActionOn catches everything and rewraps (listenarr.infrastructure/FileSystem/FileMover.Actions.cs:307-311):
catch (Exception exception) when (exception is not (OperationCanceledException or OutOfMemoryException or StackOverflowException))
{
LogMutation(FileMutationOutcome.Failed, action, source, destination, exception.Message);
throw new InvalidOperationException($"Unable to perform {action} on {source} to {destination}", exception);
}LogMutation then formats a template and calls _logger.LogError(template, arguments) at :439. The overload takes no exception, so the caught object never reaches the logger: no type, no stack, no inner exception. The Reason argument carries exception.Message and nothing else, and it goes through SanitizeText.
DownloadProcessingJobProcessor catches the wrapper and blocks the download with a fixed string (listenarr.infrastructure/Downloads/Processing/DownloadProcessingJobProcessor.cs:135-138):
download.Blocked(
"Unable to import the download",
$"See the log of job {job.Id} for more information")The job's own ProcessingLog records "Unable to perform HardlinkCopy on <source> to <destination>", which is the wrapper's message rather than the cause.
So the operator is told to see the log, and the log has an Errno-free sentence with the same wording.
Why this is worth fixing on its own
I was handed a report of 221 downloads blocked over eleven days, 155 of them with the identical "Unable to perform HardlinkCopy" signature, on a deployment whose download directory and...
Automated Canary build