chenhg5/cc-connect · error

read first-chunk body: %w

Error message

read first-chunk body: %w

What it means

Wraps an io.ReadAll failure while reading the 1-byte first chunk from a 206 Partial Content response body. This is a mid-stream network failure — connection reset, abrupt close, or context cancellation during the read. The library retries via the plain-GET fallback, but persistent transport faults will surface to the caller.

Source

Thrown at platform/feishu/resource_download.go:163

	req.Header.Set("Authorization", "Bearer "+token)
	req.Header.Set("Range", "bytes=0-0")

	resp, err := p.resourceDownloadHTTP.Do(req)
	if err != nil {
		return nil, 0, fmt.Errorf("first-chunk request: %w", err)
	}
	defer func() { _, _ = io.Copy(io.Discard, resp.Body); _ = resp.Body.Close() }()

	switch resp.StatusCode {
	case http.StatusPartialContent:
		cr := resp.Header.Get("Content-Range")
		total, ok := parseContentRangeTotal(cr)
		if !ok {
			return nil, 0, fmt.Errorf("first-chunk: 206 without parseable Content-Range %q", cr)
		}
		body, err := io.ReadAll(io.LimitReader(resp.Body, 1))
		if err != nil {
			return nil, 0, fmt.Errorf("read first-chunk body: %w", err)
		}
		return body, total, nil

	case http.StatusOK:
		// Server ignored Range and sent the full body. We deliberately
		// honour it and skip the chunked loop — this matches pre-#1741
		// behaviour for files small enough that Feishu doesn't truncate.
		body, err := io.ReadAll(io.LimitReader(resp.Body, p.resourceMaxBytes+1))
		if err != nil {
			return nil, 0, fmt.Errorf("read full body: %w", err)
		}
		if int64(len(body)) > p.resourceMaxBytes {
			return nil, 0, fmt.Errorf("resource too large: body exceeds cap %d", p.resourceMaxBytes)
		}
		return body, 0, nil

	default:
		return nil, 0, fmt.Errorf("first-chunk: unexpected status %d", resp.StatusCode)

View on GitHub (pinned to 4000b2338a)

Solutions

  1. Retry the download; the resourceRangeChunk path retries transients and resourceSingleGet is attempted as fallback
  2. Check network stability between bot host and Feishu (persistent resets indicate MTU/firewall issues)
  3. If timeouts are the cause, review overall download context deadlines in the calling code

Example fix

null
Defensive patterns

Strategy: retry

Validate before calling

null

Type guard

null

Try / catch

var ne net.Error
if errors.As(err, &ne) || isTransient(err) {
    time.AfterFunc(backoff, func() { retryDownload(msgID, key, resType) })
}

Prevention

When it happens

Trigger: After a successful 206 probe, io.ReadAll(io.LimitReader(resp.Body, 1)) errors: TCP RST, idle timeout, server closing the connection mid-body, or probeCtx cancelled/expired.

Common situations: Flaky Wi-Fi/mobile hotspots, aggressive load balancers killing keep-alive connections, Feishu-side transient 5xx close during probe.

Related errors


AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06). Data as JSON: /api/errors/5ef537834cd61956. Report an issue: GitHub.