Problem statement
The reusable GitHub Action submits all inline review candidates in a single GitHub create-review request. It has strong ambiguous-write reconciliation and retry behavior, but it does not proactively bound the number of comments in one request or the total number published inline.
Released v1.7.15 source:
https://github.com/alibaba/open-code-review/blob/v1.7.15/scripts/github-actions/post-review-comments.js#L189-L213
Production evidence:
That run attempted to publish 71 inline candidates as one review batch. GitHub returned Server Error after partial success. Reconciliation/fallback found the comments on GitHub, but the integrating workflow's summary reported only 50 inline comments. The OCR execution time was independent of this failure, but the event demonstrates that unbounded batches create delivery ambiguity and poor reviewer ergonomics at realistic comment volumes.
Existing #158 and PRs #164, #183, #250, and #337 cover rate-limit handling, fallback, idempotency markers, and ambiguous-write reconciliation. This request should preserve those guarantees rather than reopen them. The missing capability is deterministic up-front chunking and an optional inline publication cap with auditable overflow.
Proposed solution
Add configurable deterministic batching controls to the reusable GitHub Action.
Suggested inputs or equivalent configuration:
- maximum comments per GitHub review request;
- maximum comments published inline per Action run;
- overflow destination, defaulting to sticky summary plus raw artifact/output preservation;
- stable ordering policy, such as severity/category/path/line/finding identity when available;
- behavior when one batch is ambiguous or fails.
Required behavior
- Sort candidates deterministically before batching.
- Partition them into bounded batches with stable batch IDs and per-comment IDs.
- Submit batches sequentially or with explicitly safe bounded concurrency.
- After an ambiguous 5xx, 408, or network result, reconcile that batch against GitHub before retrying or moving to the next batch.
- Retry only comments proven missing under the existing idempotency contract.
- If reconciliation itself is unavailable, stop visibly rather than risking duplicates.
- Route comments beyond the configured inline cap to the sticky summary and preserve their full machine-readable records.
- Keep terminal counts mutually exclusive and reconcile them with GitHub-observed state.
- Expose raw, duplicate, historical-overlap, inline, summary-overflow, failed, ambiguous, and reconciled counts.
- Preserve current least-privilege and fork-safety behavior.
Acceptance scenarios
- 0, 1, exactly-batch-size, batch-size-plus-1, and many-comment cases produce deterministic partitions.
- A 71-candidate run with batch size 20 creates four predictable batches and accounts for all 71 findings.
- An ambiguous partial success in any batch is reconciled without duplicates before later batches proceed.
- A configured inline cap routes overflow without deleting findings.
- Rerunning the same head does not duplicate already-landed comments.
- Summary counters equal API-observed destinations.
- Existing ambiguous-write, rate-limit, and line-anchoring tests remain valid.
Alternatives considered
Keep one request and rely on fallback
Fallback prevents some data loss, but a very large request still increases the blast radius of one ambiguous response and does not control reviewer-facing comment volume.
Truncate findings before posting
Silent truncation loses review evidence. Overflow should remain visible in the sticky summary and machine-readable output.
Implement this independently in each consumer
Consumers would have to duplicate Action-owned markers, GitHub reconciliation, retry behavior, and destination accounting. Generic batching belongs beside the existing Action poster.
Affected area
- Output / Formatting
- Configuration
- Telemetry / Observability
- Other: reusable GitHub Action
Additional context
Related:
Problem statement
The reusable GitHub Action submits all inline review candidates in a single GitHub create-review request. It has strong ambiguous-write reconciliation and retry behavior, but it does not proactively bound the number of comments in one request or the total number published inline.
Released v1.7.15 source:
https://github.com/alibaba/open-code-review/blob/v1.7.15/scripts/github-actions/post-review-comments.js#L189-L213
Production evidence:
That run attempted to publish 71 inline candidates as one review batch. GitHub returned Server Error after partial success. Reconciliation/fallback found the comments on GitHub, but the integrating workflow's summary reported only 50 inline comments. The OCR execution time was independent of this failure, but the event demonstrates that unbounded batches create delivery ambiguity and poor reviewer ergonomics at realistic comment volumes.
Existing #158 and PRs #164, #183, #250, and #337 cover rate-limit handling, fallback, idempotency markers, and ambiguous-write reconciliation. This request should preserve those guarantees rather than reopen them. The missing capability is deterministic up-front chunking and an optional inline publication cap with auditable overflow.
Proposed solution
Add configurable deterministic batching controls to the reusable GitHub Action.
Suggested inputs or equivalent configuration:
Required behavior
Acceptance scenarios
Alternatives considered
Keep one request and rely on fallback
Fallback prevents some data loss, but a very large request still increases the blast radius of one ambiguous response and does not control reviewer-facing comment volume.
Truncate findings before posting
Silent truncation loses review evidence. Overflow should remain visible in the sticky summary and machine-readable output.
Implement this independently in each consumer
Consumers would have to duplicate Action-owned markers, GitHub reconciliation, retry behavior, and destination accounting. Generic batching belongs beside the existing Action poster.
Affected area
Additional context
Related:
You have exceeded a secondary rate limit and have been temporarily blocked from content creationwhen posting PR comments on Github #158