chenhg5/cc-connect · error

resource too large: body=%d exceeds cap %d

Error message

resource too large: body=%d exceeds cap %d

What it means

Thrown when the Feishu server ignored the Range header and returned the entire resource in one 200 response, and that body is larger than resourceMaxBytes (the in-memory download cap). The library buffers downloads in memory and enforces this cap to prevent OOM from oversized files. The error reports the actual body size and the configured cap.

Source

Thrown at platform/feishu/resource_download.go:120

// resourceDownloadStream executes the actual download. Split out so the
// helper's preflight (validation, token, defaults) stays readable.
func (p *Platform) resourceDownloadStream(ctx context.Context, token, messageID, fileKey, resType string) ([]byte, error) {
	probeCtx, cancel := context.WithTimeout(ctx, resourceRangeProbeTimeout)
	defer cancel()

	first, total, err := p.resourceFetchFirstChunk(probeCtx, token, messageID, fileKey, resType)
	if err != nil {
		// Fallback: try a single plain GET. Some servers reject Range entirely
		// with 4xx instead of silently ignoring it.
		slog.Warn(p.tag()+": first-chunk fetch failed; trying plain GET",
			"error", err, "file_key", fileKey, "type", resType)
		return p.resourceSingleGet(ctx, token, messageID, fileKey, resType)
	}

	// Server ignored our Range header and sent the whole body in one 200.
	if total == 0 {
		if int64(len(first)) > p.resourceMaxBytes {
			return nil, fmt.Errorf("resource too large: body=%d exceeds cap %d", len(first), p.resourceMaxBytes)
		}
		return first, nil
	}

	// Server honoured Range. Loop the remaining chunks.
	if total > p.resourceMaxBytes {
		return nil, fmt.Errorf("resource too large: total=%d exceeds cap %d", total, p.resourceMaxBytes)
	}
	if int64(len(first)) >= total {
		// Defensive: a server that advertises 206 with first slice already
		// covering the whole resource is fine — return what we have.
		return first, nil
	}
	return p.resourceFetchRemainingChunks(ctx, token, messageID, fileKey, resType, total, first)
}

// resourceFetchFirstChunk issues Range bytes=0-0 to learn the total and grab
// the first byte. Returns (first, total, nil) where total==0 means the

View on GitHub (pinned to 4000b2338a)

Solutions

  1. Raise resource_max_bytes in config.toml if the file size is acceptable for memory
  2. Tell the sender the file exceeds the bot's size cap; deliver via a link instead of download
  3. Investigate intermediaries (proxy) that strip the Range header, forcing whole-body responses

Example fix

// before (config.toml)
# resource_max_bytes not set  -> default cap
// after
[platform.feishu]
resource_max_bytes = 104857600  # 100 MiB
Defensive patterns

Strategy: validation

Validate before calling

if fileSizeKnown && fileSize > maxResourceBytes { skipDownload("file too large") }

Type guard

null

Try / catch

data, err := downloadResourceChunked(ctx, msgID, key, "file")
if err != nil && strings.HasPrefix(err.Error(), "resource too large") {
    reply("Sorry, that file exceeds the bot's download limit.")
    return
}

Prevention

When it happens

Trigger: resourceFetchFirstChunk received HTTP 200 (total==0, whole body delivered) for a resource whose downloaded size exceeds p.resourceMaxBytes, e.g. a user sends a very large file to the bot.

Common situations: Users sending 100+ MB files through Feishu chat while resource_max_bytes is at its default; or a proxy/CDN stripping the Range header so large files always arrive as one full 200 body.

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


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