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.

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)

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(); }
Defensive patterns

Strategy: try-catch

Try / catch

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;
}

Prevention

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


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