From f4b57be67c34e9d771859b6851254e64c2a1dc8c Mon Sep 17 00:00:00 2001 From: Julian Andres Klode Date: Mon, 18 Nov 2024 14:54:19 +0100 Subject: Handle Retry-After by default Let's get some feedback here. This is capped to 30s per retry, so a maximum of 90s per item that we delay the failure case. In the worst case, we hence have 90n seconds delay for n items. In a more realistic worse case however, the server likely does not collapse per-item, and we end up trying all items in a short burst so it seems more realistic we hit a 90s total delay. The bursty behavior may be suboptimal; we don't quite know, but it seems the specification of Retry-After is per-entity rather than per-host, so technically speaking it seems correct. --- apt-pkg/acquire-worker.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'apt-pkg') diff --git a/apt-pkg/acquire-worker.cc b/apt-pkg/acquire-worker.cc index f4326ab03..0f22f71e8 100644 --- a/apt-pkg/acquire-worker.cc +++ b/apt-pkg/acquire-worker.cc @@ -649,7 +649,7 @@ void pkgAcquire::Worker::HandleFailure(std::vector const &It { auto Iter = _config->FindI("Acquire::Retries", 3) - Owner->Retries - 1; auto const MaxDur = _config->FindI("Acquire::Retries::Delay::Maximum", 30); - auto const handleRetryAfter = _config->FindB("Acquire::Retries::HandleRetryAfter", false); + auto const handleRetryAfter = _config->FindB("Acquire::Retries::HandleRetryAfter", true); auto Dur = std::chrono::seconds(1 << Iter); auto const retryAfterStr = LookupTag(Message, "Retry-After"); auto const failReason = LookupTag(Message, "FailReason"); -- cgit v1.2.3-70-g09d2