chunk_%d: giving up after %d retries while server is overloa

Error message

chunk_%d: giving up after %d retries while server is overloaded

What it means

Emitted by the chunk download loop when errOverloadRetry (a 429/502/503/504-class response on a non-first chunk) has been retried more than PartBodyMaxRetries*10 times. The loop backs off linearly (100ms per attempt, capped at 2s) and then gives up, converting a persistent server-overload condition into a hard failure for that chunk.

Source

Thrown at internal/net/request.go:370

		// If this occurs we unwrap the err to set the underlying error
		// and attempt any remaining retries.
		if e, ok := err.(*errNeedRetry); ok {
			err = e.Unwrap()
			if n > 0 {
				// 测试：下载时 断开 alist向云盘发起的下载连接
				// 校验：下载完后校验文件哈希值 一致
				d.incrWritten(n)
				ch.start += n
				ch.size -= n
				params.Range.Start = ch.start
				params.Range.Length = ch.size
			}
			log.Warnf("err chunk_%d, object part download error %s, retrying attempt %d. %v",
				ch.id, params.URL, retry, err)
		} else if err == errOverloadRetry {
			overloadRetry++
			if overloadRetry > d.cfg.PartBodyMaxRetries*10 {
				err = fmt.Errorf("chunk_%d: giving up after %d retries while server is overloaded", ch.id, overloadRetry)
				break
			}
			backoff := time.Duration(overloadRetry) * 100 * time.Millisecond
			if backoff > 2*time.Second {
				backoff = 2 * time.Second
			}
			select {
			case <-d.ctx.Done():
				return d.ctx.Err()
			case <-time.After(backoff):
			}
			retry--
			continue
		} else {
			break
		}
	}

View on GitHub (pinned to 843d9dc814)

Solutions

Retry the whole download later with backoff — the server is overloaded, not the client broken.
Raise cfg.PartBodyMaxRetries to enlarge the overload retry budget.
Reduce chunk concurrency to lower request pressure on the server.
Check whether the storage endpoint has known rate limits and space requests accordingly.

Defensive patterns

Strategy: retry

Type guard

strings.Contains(err.Error(), "giving up after")

Try / catch

err := download()
if err != nil && strings.Contains(err.Error(), "server is overloaded") {
    // exponential backoff at the task level, retry whole download later
    scheduleRetry(2*time.Minute)
}

Prevention

Tune PartBodyMaxRetries relative to how long your upstream throttles.
Reduce chunk concurrency to avoid triggering 429s in the first place.
Apply whole-task backoff when overload errors repeat, not immediate tight retries.

When it happens

Trigger: A remote server continuously returning 429/502/503/504 for chunk ranges; PartBodyMaxRetries configured very low so the *10 budget is small; a proxy or CDN throttling the client for the whole download duration.

Common situations: Cloud drive rate limiting sustained over minutes; upstream outage during a large file download; aggressive CDN throttle on ranged requests.

Related errors

AI-assisted analysis of AlistGo/alist@843d9dc814 (2026-08-15). Data as JSON: /api/errors/5bbcd1974c657a8c. Report an issue: GitHub.