Since you have multiple systems, would you consider downgrading one to 2.0.2.1 Beta?
Knowing whether or not the bug is in Beta seems important before Beta becomes Stable.
I “think” DB versions are the same, at 9 for server database and 17 for the job databases.
There’s now Duplicati.CommandLine.DatabaseTool.exe, and also Recreate if needed.
No “missing files” reported today. The Windows 10 system did report fixing a faulty index file - I have still been seeing these occasionally and haven’t given them much thought, but I am now wondering if they may also be related….
I am giving this some thought….
Did you really mean 2.0.2.1? Or 2.1.2.1 (from Oct. 3)?
Sorry. 2.1.2.1. 2.0.2.1 does exist, but it’s 2017 so definitely a bigger than desired downgrade.
No problem! I went ahead and downgraded one of my Fedora 42 systems to 2.1.2.1. Will try to downgrade my Windows 10 system later today. The Fedora system is the least likely to encounter the issue (very little data changes on it most days), while the Windows system is the most likely to encounter it (even though there is little user data changes on it most days).
That looks correct, there is no check on the status code. It does check if the response is valid, but maybe that passes?
I have a PR ready here that adds a status code check:
If this is indeed the cause, the problem exists in the beta builds as well.
The old logic (does it still apply?) is a try/catch where catch treats 500 series errors specially.
EDIT 1:
I know that I used to see 503 status recognized, as I had number-of-retries=0 to die easily.
Searching my emailed error collection, last was from 2.1.0.105_canary_2025-01-07 Jan 2025.
There is a try/catch that resets the upload url, so a new one is fetched if the upload fails.
Other than that, I don’t see 5xx errors treated specially.
We might be talking about the same thing. I guess this is how bad status was caught:before:
and I was just wondering how this meshes with the new check on the status code. All still OK?
The exception thrown on the status check is being picked up with GetExceptionStatusCode().
The logic here is that if the error is 5xx, then we cannot reuse the upload url.
The effect of this is that the next upload attempt will fetch a fresh upload url.
This has no real effect, because the backend instance is disposed after an error, so the url would not be reused in case of errors anyway.
The three systems I have been reporting on here have all been upgraded to 2.1.1.105. No errors reported on the initial post-upgrade backups other than fixing an index file.
No errors reported today.
No errors reported today, including a 4th system I upgraded yesterday.