paperclipai/paperclip · error · GitHubAttachmentUnavailableError

github_attachment_canonical_api_too_large

github_attachment_canonical_api_too_large

Error message

github_attachment_canonical_api_too_large

What it means

While streaming the canonical GitHub API response body, githubAttachmentCommentFetch accumulates bytes and aborts with GitHubAttachmentUnavailableError('github_attachment_canonical_api_too_large') as soon as the cumulative size exceeds MAX_COMMENT_RESPONSE_BYTES. This guards against a lying or absent Content-Length and caps memory use before the body is parsed.

Solutions

1. Reduce the comment size on GitHub (shorten body, remove large HTML blocks) and re-attach the file.
2. Check the server's MAX_COMMENT_RESPONSE_BYTES configuration if large attachments are legitimate for your deployment.
3. If the Content-Length header check passed but the stream still overflowed, verify the proxy/upstream is not inflating the response (e.g. injecting content or re-encoding).

Example fix

// before: trusting Content-Length alone
if (Number(res.headers.get('content-length') ?? 0) > MAX) throw new TooLarge();
// after: also enforce the cap while streaming
let size = 0;
for await (const chunk of res.body) { size += chunk.byteLength; if (size > MAX) throw new TooLarge(); }

try {
  const value = await fetchCanonicalComment(url, signal);
} catch (e) {
  if (e instanceof GitHubAttachmentUnavailableError && e.code === 'github_attachment_canonical_api_too_large') {
    log.warn('comment response exceeded byte cap', { url });
    return { kind: 'unavailable', reason: 'too_large' };
  }
  throw e;
}

When it happens

Trigger: The streamed body of the canonical comment API response exceeds MAX_COMMENT_RESPONSE_BYTES mid-read, either because Content-Length was absent/incorrect (chunked transfer) or because the comment payload genuinely grew beyond the cap between the header check and the stream.

Common situations: A very large comment body or HTML rendering pushed a comment past the byte cap; a compromised/misbehaving upstream sends chunked data without Content-Length, bypassing the header check but hitting the stream counter.

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

• CreateOS process frame is too large.
• github_attachment_canonical_api_access_denied |…
• github_attachment_empty
• github_attachment_invalid_response
• OpenCode event stream returned HTTP

AI-assisted analysis of paperclipai/paperclip@01ad858492 (2026-09-10). Data as JSON: /api/errors/679b9b6e738595bd. Report an issue: GitHub.

Appendix: source

Thrown at server/src/services/chat-github-attachments.ts:500

              : "github_attachment_canonical_api_invalid_response",
      );
    }
    const reader = response.body.getReader();
    const chunks: Uint8Array[] = [];
    let size = 0;
    const cancel = () => {
      void reader.cancel().catch(() => undefined);
    };
    signal.addEventListener("abort", cancel, { once: true });
    try {
      for (;;) {
        signal.throwIfAborted();
        const next = await reader.read();
        signal.throwIfAborted();
        if (next.done) break;
        size += next.value.byteLength;
        if (size > MAX_COMMENT_RESPONSE_BYTES)
          throw new GitHubAttachmentUnavailableError(
            "github_attachment_canonical_api_too_large",
          );
        chunks.push(next.value);
      }
    } finally {
      signal.removeEventListener("abort", cancel);
      await reader.cancel().catch(() => undefined);
    }
    return new Response(Buffer.concat(chunks), {
      status: 200,
      headers: { "content-type": "application/json" },
    });
  };
}

/**
 * The authenticated rendering is evidence only for this exact unchanged source.
 * We support GitHub's image anchor mapping, not arbitrary HTML URL extraction.

View on GitHub (pinned to 01ad858492)