chenhg5/cc-connect · error
weixin: %s: response body exceeds %d bytes
Error message
weixin: %s: response body exceeds %d bytes
What it means
post() rejects any response body larger than maxIlinkHTTPResponseBody (64 MiB). Because the read is capped with io.LimitReader(limit+1), a body of limit+1 bytes proves truncation, so the partial data is discarded rather than parsed as truncated JSON.
Source
Thrown at platform/weixin/client.go:112
}
client := c.httpClient
if timeout > 0 {
// Dedicated client so long-poll does not inherit short Timeout from default client.
client = c.longPollClient(timeout)
}
resp, err := client.Do(req)
if err != nil {
return nil, fmt.Errorf("weixin: %s: %w", label, err)
}
defer resp.Body.Close()
raw, err := io.ReadAll(io.LimitReader(resp.Body, maxIlinkHTTPResponseBody+1))
if err != nil {
return nil, fmt.Errorf("weixin: %s: read body: %w", label, err)
}
if len(raw) > maxIlinkHTTPResponseBody {
return nil, fmt.Errorf("weixin: %s: response body exceeds %d bytes", label, maxIlinkHTTPResponseBody)
}
if resp.StatusCode != http.StatusOK {
return nil, fmt.Errorf("weixin: %s: http %d: %s", label, resp.StatusCode, truncateForLog(raw, 512))
}
return raw, nil
}
func truncateForLog(b []byte, max int) string {
s := string(b)
if len(s) <= max {
return s
}
return s[:max] + "…"
}
func (c *apiClient) getUpdates(ctx context.Context, buf string, timeoutMs int) (*getUpdatesResp, error) {
timeout := defaultLongPollTimeout
if timeoutMs > 0 {View on GitHub (pinned to 4000b2338a)
Solutions
- Drain the backlog: reconnect regularly so getUpdates batches stay small
- Raise maxIlinkHTTPResponseBody in platform/weixin/client.go if your workload legitimately needs larger batches (and re-test)
- Confirm base_url points at the real iLink API, not an unexpected endpoint
- Reduce message ingest rate or media sizes flowing through the weixin channel
Example fix
// before const maxIlinkHTTPResponseBody = 64 << 20 // after (if large batches are legitimate) const maxIlinkHTTPResponseBody = 256 << 20
Defensive patterns
Strategy: validation
Validate before calling
// keep getUpdates buffers small so responses stay well under the cap
if len(pendingBuf) > 0 { /* flush/ack promptly instead of accumulating */ } Prevention
- Poll frequently so getUpdates never accumulates a giant message backlog
- Raise maxIlinkHTTPResponseBody only after confirming large batches are legitimate
- Verify base_url points at the real API to avoid huge unexpected payloads
- Bound per-message media sizes upstream of the channel
When it happens
Trigger: An API response (most plausibly getUpdates batching many messages) exceeds 64 MiB of JSON.
Common situations: A huge backlog of undelivered messages delivered in one long-poll batch; pathological/misbehaving server or a wrong base_url pointing at something streaming huge payloads.
Understand the failure class
Background: "File too large" / "file size exceeds limit" errors: why libraries cap file sizes and how to fix them — this error's family across 46 libraries.
Related errors
- download exceeds --max-bytes: %d > %d
- http %d: %s
- get_bot_qrcode: %w
- get_qrcode_status http %d: %s
- attachment exceeds %d bytes
AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06).
Data as JSON: /api/errors/76836296f0a182b0.
Report an issue: GitHub.