What happened
PR #2850 received 6 review agent runs over 8 days (Jul 1–9). The consolidated sticky review comment grew to 29,246 characters containing 13 'Previous run' collapsible sections — more than 2x the actual run count. SHA occurrence analysis reveals quadratic duplication: SHA 2a3d0a5 (first review) appears 6 times in the comment body; 925fadf appears 6 times; 443e737 appears 6 times; 307cb63 appears 4 times; b1bbd14 appears 5 times. Each new review run embedded the entire previous sticky comment — including its own history sections — as a new 'Previous run' block, causing earlier review content to be nested and duplicated with each iteration.
What could go better
The sticky comment mechanism should not embed full prior content (including prior history sections) inside each new history entry. With 6 runs, the comment reached 29K chars; with 10+ runs it would approach GitHub's 65,536 char limit as #2358 predicted. The PR #2850 data adds a specific insight: the growth is not merely linear (one section per run) but quadratic due to nested embedding — SHAs from early runs appear up to 6 times, meaning ~80% of the comment body is duplicate content. Confidence: high — the SHA duplication counts are objective.
Proposed change
This is additional evidence for #2358. When implementing the cap proposed in that issue, also address the nesting root cause: the post-review script should strip sticky:history-start/sticky:history-end content from the previous comment body before wrapping it in a new 'Previous run' details block. This would convert O(n2) growth to O(n). The implementation likely lives in the review post-script that assembles the consolidated sticky comment.
Validation criteria
On a PR with 6+ review iterations, each historical SHA should appear at most twice in the sticky comment body (once in the current review referencing prior findings, once in its own history section). The total comment size should scale linearly with the number of review iterations, not quadratically. The 29K-char comment from PR #2850 (6 runs) should have been ~10K chars without duplication.
Generated by retro agent from #2850
What happened
PR #2850 received 6 review agent runs over 8 days (Jul 1–9). The consolidated sticky review comment grew to 29,246 characters containing 13 'Previous run' collapsible sections — more than 2x the actual run count. SHA occurrence analysis reveals quadratic duplication: SHA
2a3d0a5(first review) appears 6 times in the comment body;925fadfappears 6 times;443e737appears 6 times;307cb63appears 4 times;b1bbd14appears 5 times. Each new review run embedded the entire previous sticky comment — including its own history sections — as a new 'Previous run' block, causing earlier review content to be nested and duplicated with each iteration.What could go better
The sticky comment mechanism should not embed full prior content (including prior history sections) inside each new history entry. With 6 runs, the comment reached 29K chars; with 10+ runs it would approach GitHub's 65,536 char limit as #2358 predicted. The PR #2850 data adds a specific insight: the growth is not merely linear (one section per run) but quadratic due to nested embedding — SHAs from early runs appear up to 6 times, meaning ~80% of the comment body is duplicate content. Confidence: high — the SHA duplication counts are objective.
Proposed change
This is additional evidence for #2358. When implementing the cap proposed in that issue, also address the nesting root cause: the post-review script should strip
sticky:history-start/sticky:history-endcontent from the previous comment body before wrapping it in a new 'Previous run' details block. This would convert O(n2) growth to O(n). The implementation likely lives in the review post-script that assembles the consolidated sticky comment.Validation criteria
On a PR with 6+ review iterations, each historical SHA should appear at most twice in the sticky comment body (once in the current review referencing prior findings, once in its own history section). The total comment size should scale linearly with the number of review iterations, not quadratically. The 29K-char comment from PR #2850 (6 runs) should have been ~10K chars without duplication.
Generated by retro agent from #2850