Conversation
SplitComment breaks a formatted report into chunks under a size limit, closing and reopening markdown structures (code fences, <details>) at chunk boundaries so every chunk renders valid on its own. Fence detection is line-anchored and marker-aware (```` vs ```, ~~~), matching how VCS renderers parse fences. Chunks are carved from the end of the report so the plan summary tail always survives; past the chunk cap the head is truncated with a warning instead. Refs diggerhq#1645
Optional CommentMaxLengthProvider interface lets PullRequestService implementations declare their comment body limit: GitHub 65,536, Bitbucket 32,768, Azure DevOps 150,000. Callers fall back to GitHub's limit when a service does not implement it. Refs diggerhq#1645
Declare GitLab's 1,000,000-character comment limit and populate the web URL of published notes (the Notes API does not return one) so comments can be linked to. Handles self-hosted instances under a path prefix. Refs diggerhq#1645
GitHub rejects comment bodies over 65,536 characters, so a large terraform plan failed the job with 422 even though the plan itself succeeded. Setting reporting-strategy made no difference: a single oversized report failed on create, and the per-run strategies kept PATCHing a shared comment until every later project's report was lost. - multiple_comments publishes one comment per chunk - per-run strategies leave the full existing comment untouched on overflow and continue in new comment(s) under the same title; title matching targets the newest comment so later reports append to the continuation - continuation comments link back to their predecessor; the URL is substituted at publish time with a size reserve - guard against providers that do not return the created comment Closes diggerhq#1645
A blank line after </summary> is required for markdown (links, bold, fences) to render inside an HTML details block. The old template also indented content, and re-wrapping on every appended report accumulated two more spaces each time until content turned into a markdown code block.
Drift issues share GitHub's 65,536-character limit. The previous truncation cut the head of the plan at the limit, which could land inside a code fence and always discarded the tail where warnings and the plan summary live. Reuse the comment splitter with a single-chunk cap: structure-aware truncation that drops the head and keeps the summary. Refs diggerhq#1645
Env-gated tests against real APIs: GitHub (oversized plan splitting, per-run overflow continuation, drift issue truncation), GitLab (splitting via discussions, backlink URL correctness) and Bitbucket (genuine 32,768 limit, full per-run overflow flow). Refs diggerhq#1645
Author
|
@motatoes, would you have a chance to take a look at this PR? I’m running into this issue with larger plans, particularly for providers like Auth0, Okta, and Datadog. Happy to provide any additional context or make changes if helpful. Thank you and your team for creating digger! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
GitHub rejects comment bodies over 65,536 characters. When a terraform plan output exceeds that, Digger fails the whole job with exit code 5 even though the plan succeeded:
error editing comment: PATCH https://api.github.com/repos/.../issues/comments/...: 422 Validation Failed [{Resource:IssueComment Field:body Code:custom Message:body is too long (maximum is 65536 characters)}]
Setting
reporting-strategydoesn't help (see #1645 discussion): a single oversized report fails on create withmultiple_comments, and the per-run strategies keep PATCHing a shared comment until every later project's report is lost — with 20+ projects, everything after the comment fills up fails.Fixes #1645
What this does
splitter closes open structures (code fences,
<details>) at each chunkboundary and reopens them in the next chunk, so every comment renders
valid on its own. Fence detection is line-anchored and marker-aware
(
````vs```,~~~), matching how renderers actually parsefences — a plan containing a literal
```inside a string value can'tdesync the splitter.
summary, warnings, errors) always survives. A single report is capped at
10 comments; beyond that the head is truncated with a warning.
comments_per_run,latest_run_comment) leavethe full existing comment untouched on overflow and continue in new
comment(s) under the same title; later reports append to the newest
continuation.
navigable when parallel projects interleave.
ci.CommentMaxLengthProviderinterface: GitHub 65,536 / GitLab 1,000,000 / Bitbucket 32,768 / Azure
DevOps 150,000. No breaking interface changes; behavior for reports under
the limit is unchanged.
structure-aware truncation that keeps the plan summary instead of cutting
mid-fence and dropping the tail.
</summary>suppressed markdown; re-wrapping on append accumulatedindentation until content rendered as a code block).
Testing
boundaries, renderer-faithful fence parsing) and all three strategies.
issue truncation at the real 65,536 boundary
uses: GLEF1X/digger@fix/1645-split-long-commentsin no-backend mode:Digger comment splitting: oversized plan output (#1645) GLEF1X/demo-opentofu#2 — a ~230KB OpenTofu plan
(~4x the limit) posts as a chain of five linked comments plus a
continuation for the second project, job exits 0. On current Digger this
exact scenario fails with the 422 above.
🧠 Ai UsageDetails (if applicable):
IMPORTANT: Please disclose any usage of ai tooling while making this change. If you did not use any AI write "NA" below
Some parts of the code, including tests and comments for methods, functions, and constants, etc were generated by Codex. I also used Codex to better understand the codebase and ask questions about it. I reviewed and verified all generated code and manually performed e2e testing in accordance with the contribution guidelines.