chenhg5/cc-connect · error

resource size mismatch: assembled=%d expected=%d

Error message

resource size mismatch: assembled=%d expected=%d

What it means

After fetching all chunks in resourceFetchRemainingChunks, the library verifies that the assembled buffer length equals the total size reported by the initial size probe (Content-Range total). If they differ, the download is inconsistent — some chunk came back short or the server returned fewer bytes than promised — and the library discards the data and returns this error rather than delivering a corrupt file.

Source

Thrown at platform/feishu/resource_download.go:214

	chunks := 1 // count the first byte we already have
	for offset := int64(1); offset < total; offset += chunkSize {
		end := offset + chunkSize - 1
		if end >= total {
			end = total - 1
		}
		n, err := p.resourceRangeChunk(ctx, token, messageID, fileKey, resType, offset, end, total)
		if err != nil {
			return nil, fmt.Errorf("resource chunk offset=%d: %w", offset, err)
		}
		buf.Write(n)
		chunks++
		if err := ctx.Err(); err != nil {
			return nil, err
		}
	}

	if int64(buf.Len()) != total {
		return nil, fmt.Errorf("resource size mismatch: assembled=%d expected=%d", buf.Len(), total)
	}
	slog.Info(p.tag()+": resource chunked download complete",
		"file_key", fileKey, "type", resType, "total", total, "chunks", chunks,
		"chunk_size", chunkSize)
	return buf.Bytes(), nil
}

// parseContentRangeTotal extracts the "total" field from a Content-Range
// header of the form "bytes 0-0/12345". Returns false if the header is
// malformed or uses a unit we don't recognise.
func parseContentRangeTotal(h string) (int64, bool) {
	h = strings.TrimSpace(h)
	slash := strings.LastIndex(h, "/")
	if slash < 0 || slash == len(h)-1 {
		return 0, false
	}
	totalStr := strings.TrimSpace(h[slash+1:])
	if totalStr == "*" {

View on GitHub (pinned to 4000b2338a)

Solutions

1. Retry the whole download — the size probe runs again, so a transient truncation usually resolves
2. Confirm the message/file_key still refers to an unchanged resource; re-request the file from the sender if it was replaced
3. Check for proxies/middleboxes that can truncate HTTP responses and bypass them
4. If it persists, fall back to resourceSingleGet for the resource (bypass chunk assembly) if the size permits
5. Log the wrapped sizes (assembled vs expected) and compare with the server's Content-Range totals to identify which chunk was short

data, err := p.resourceDownloadStream(ctx, token, msgID, fileKey, resType)
if err != nil {
    var sizeErr = "resource size mismatch"
    if strings.Contains(err.Error(), sizeErr) {
        // re-run: the size probe re-executes, recovering from a changed file
        return p.resourceDownloadStream(ctx, token, msgID, fileKey, resType)
    }
    return err
}

When it happens

Trigger: A Range chunk returns fewer bytes than requested (end-start+1) without an error; the probed total from the size probe changed server-side between probe and download (file replaced mid-download); a chunk response includes unexpected body length while still being status 206.

Common situations: File was modified or deleted on the Feishu server between the size probe and the chunk downloads; a proxy truncated a chunk body; server-side rate limiting caused an incomplete but non-error chunk response; concurrent re-upload of the same message resource.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors

• resource chunk offset=%d: %w
• build range request: %w
• range request: %w
• app_id/app_secret are required
• invalid remote image URL

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