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
- Retry the download; the resourceRangeChunk path retries transients and resourceSingleGet is attempted as fallback
- Check network stability between bot host and Feishu (persistent resets indicate MTU/firewall issues)
- 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
- Run the bot on stable network paths; avoid NAT gateways with short idle timeouts
- Enable TCP keepalives on the host
- Retry downloads on transient errors — the library already retries range chunks, add app-level retry for the probe path
- Watch for persistent resets which indicate MTU/firewall problems
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
- read full body: %w
- read body from %s: %w
- openai tts: read audio: %w
- %s: resource download auth: %w
- first-chunk request: %w
AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06).
Data as JSON: /api/errors/5ef537834cd61956.
Report an issue: GitHub.