With stale locks the return code is 0. IMO this is not a successful run and should indicate this with a not-null return code. This is important for scripted and unattended backups.
Return codes are not currently covering all cases afaik. You can follow this related issue: https://github.com/restic/restic/issues/956
@aggsol I’m not really following what you mean is the problem, because:
backupcommand will successfully back up data even if the repository has a stale lock, with an exit code of 0 which is proper, so that’s not an issue.
prunecommands will refuse to work (citing a stale lock preventing new lock creation) when there’s a stale lock, giving exit code 1 which is proper, so that’s not an issue (I just tested it).
So what is the problem you’re referring to? Please be more specific.
You are right, I mixed prune and backup return codes in my Bash script. This is an non-issue now.