a3ecbcc7f6
While the 429 retry-after HTTP error handling for the storage endpoint works just as expected, the same was not true for batch API endpoint. In case of a 429 error, the call to the batch API endpoint would be retried as well as the `retry-after` HTTP header honoured correctly, but the LFS command would still exit with a generic `LFS: Error` message. This was caused by the fact, that while the retry-able error from the `Batch` method was correctly overwritten by `nil` in case it of a retry, it would finally again be converted into a retry-able error and hence be no longer `nil`. This would lead to a bubble-up of the original 429 retry-able HTTP error to the final error check, altough the exact operation was successfully retried. Furthermore, the overwrite with `nil` during correct handling of the first object caused all subsequent objects to fail and hence never being enqueued for retrial. This was solved by removing the immediate overwrite by `nil` in case of a retry-able-later error and doing the final error conversion based on the whole batch result instead of a single object result. |
||
---|---|---|
.. | ||
schemas | ||
adapterbase.go | ||
api_test.go | ||
api.go | ||
basic_download.go | ||
basic_upload.go | ||
custom_test.go | ||
custom.go | ||
errors_test.go | ||
errors.go | ||
manifest_test.go | ||
manifest.go | ||
meter.go | ||
ssh.go | ||
transfer_queue_test.go | ||
transfer_queue.go | ||
transfer_test.go | ||
transfer.go | ||
tus_upload.go | ||
verify_test.go | ||
verify.go |