chenhg5/cc-connect · warning

resource too large: Content-Length=%d exceeds cap %d

Error message

resource too large: Content-Length=%d exceeds cap %d

What it means

During a single-GET download the response's Content-Length exceeds the platform's configured resourceMaxBytes cap, so the library refuses to download the file to protect memory. This is a deliberate guard against oversized resources, not a transport failure.

Source

Thrown at platform/feishu/resource_download.go:273

	req, err := http.NewRequestWithContext(ctx, http.MethodGet, p.resourceURL(messageID, fileKey, resType), nil)
	if err != nil {
		return nil, fmt.Errorf("build request: %w", err)
	}
	req.Header.Set("Authorization", "Bearer "+token)

	resp, err := p.resourceDownloadHTTP.Do(req)
	if err != nil {
		return nil, fmt.Errorf("resource request: %w", err)
	}
	defer func() { _ = resp.Body.Close() }()

	if resp.StatusCode < 200 || resp.StatusCode >= 300 {
		body, _ := io.ReadAll(io.LimitReader(resp.Body, 4*1024))
		return nil, fmt.Errorf("resource API status=%d body=%q", resp.StatusCode, strings.TrimSpace(string(body)))
	}

	if cl := resp.ContentLength; cl > p.resourceMaxBytes {
		return nil, fmt.Errorf("resource too large: Content-Length=%d exceeds cap %d", cl, p.resourceMaxBytes)
	}

	// LimitReader caps the body too in case the server lies about
	// Content-Length; we read up to cap+1 bytes to detect the lie.
	data, err := io.ReadAll(io.LimitReader(resp.Body, p.resourceMaxBytes+1))
	if err != nil {
		return nil, fmt.Errorf("read resource: %w", err)
	}
	if int64(len(data)) > p.resourceMaxBytes {
		return nil, fmt.Errorf("resource too large: body exceeds cap %d", p.resourceMaxBytes)
	}
	slog.Debug(p.tag()+": resource downloaded (single GET)",
		"file_key", fileKey, "type", resType, "size", len(data))
	return data, nil
}

// resourceRangeChunk fetches a single byte range and verifies the
// Content-Range header agrees with what we asked for. Returns the bytes

View on GitHub (pinned to 4000b2338a)

Solutions

  1. Raise resourceMaxBytes in the Feishu platform config to accommodate the file sizes you expect
  2. Reject the download upstream: check the message's file size metadata against the cap before attempting download and inform the user the file is too large
  3. Ensure the chunked path is used for large files — the single-GET path is only for small files/probe failures, so fix the size probe if it is incorrectly falling back
  4. If downloads of large files are genuinely needed, stream to disk instead of enforcing an in-memory cap

Example fix

// before: config.toml
[platforms.feishu]
resource_max_bytes = 10485760  # 10 MB
// after
[platforms.feishu]
resource_max_bytes = 104857600  # 100 MB
Defensive patterns

Strategy: validation

Validate before calling

// check size from message metadata before download
if fileSizeBytes > maxAllowedBytes {
    return fmt.Errorf("file too large: %d bytes (max %d)", fileSizeBytes, maxAllowedBytes)
}

Try / catch

data, err := p.resourceDownloadStream(ctx, token, msgID, fileKey, resType)
if err != nil {
    if strings.Contains(err.Error(), "resource too large") {
        return nil, ErrFileTooLarge // surface a friendly user message
    }
    return err
}

Prevention

When it happens

Trigger: resourceSingleGet receives a 2xx response whose resp.ContentLength is greater than p.resourceMaxBytes — i.e. the file being downloaded is larger than the configured maximum.

Common situations: User sends a very large file (video, archive) to the bot and the agent requests it as an attachment; resourceMaxBytes configured too low for the team's normal file sizes; resourceMaxBytes left at a conservative default.

Understand the failure class

Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.

Related errors

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