KurlesHS/restic
1
0
Fork 0
forked from TrueCloudLab/restic
Code Pull requests Activity
restic/changelog/0.17.1_2024-09-05/issue-5005

17 lines
620 B
Text
Raw Normal View History

backend/retry: don't trip circuit breaker if context is canceled When the context used for a load operation is canceled, then the result is always an error independent of whether the file could be retrieved from the backend. Do not false positively trip the circuit breaker in this case. The old behavior was problematic when trying to lock a repository. When `Lock.checkForOtherLocks` listed multiple lock files in parallel and one of them fails to load, then all other loads were canceled. This cancelation was remembered by the circuit breaker, such that locking retries would fail.
2024-08-22 21:16:12 +00:00
Bugfix: Fix rare failures to retry locking a repository
cleanup changelogs
2024-08-30 12:58:32 +00:00
Restic 0.17.0 could in rare cases fail to retry locking a repository if one of
the lock files failed to load, resulting in the error:
backend/retry: don't trip circuit breaker if context is canceled When the context used for a load operation is canceled, then the result is always an error independent of whether the file could be retrieved from the backend. Do not false positively trip the circuit breaker in this case. The old behavior was problematic when trying to lock a repository. When `Lock.checkForOtherLocks` listed multiple lock files in parallel and one of them fails to load, then all other loads were canceled. This cancelation was remembered by the circuit breaker, such that locking retries would fail.
2024-08-22 21:16:12 +00:00
cleanup changelogs
2024-08-30 12:58:32 +00:00
```
unable to create lock in backend: circuit breaker open for file <lock/1234567890>
```
doc: Polish unreleased changelogs
2024-08-31 15:28:24 +00:00
This issue has now been addressed. The error handling now properly retries the
cleanup changelogs
2024-08-30 12:58:32 +00:00
locking operation. In addition, restic waits a few seconds between locking
retries to increase chances of successful locking.
backend/retry: don't trip circuit breaker if context is canceled When the context used for a load operation is canceled, then the result is always an error independent of whether the file could be retrieved from the backend. Do not false positively trip the circuit breaker in this case. The old behavior was problematic when trying to lock a repository. When `Lock.checkForOtherLocks` listed multiple lock files in parallel and one of them fails to load, then all other loads were canceled. This cancelation was remembered by the circuit breaker, such that locking retries would fail.
2024-08-22 21:16:12 +00:00
https://github.com/restic/restic/issues/5005
https://github.com/restic/restic/pull/5011
lock: introduce short delay between failed locking retries Failed locking attempts were immediately retried up to three times without any delay between the retries. If a lock file is not found while checking for other locks, with the reworked backend retries there is no delay between those retries. This is a problem if a backend requires a few seconds to reflect file deletions in the file listings. To work around this problem, introduce a short exponentially increasing delay between the retries. The number of retries is now increased to 4. This results in delays of 5, 10 and 20 seconds between the retries.
2024-08-23 21:24:43 +00:00
https://github.com/restic/restic/pull/5012
Copy permalink