Problem
submit_pull_request_review accepts max > 1, and scheduled workflows with target: "*" can emit multiple calls with different pull_request_number values. The runtime accepts every call but finalizes only one review:
- target/review context comes from the first call;
- body/event metadata comes from the last call;
- intermediate calls are silently lost;
- the workflow can still conclude successfully.
Source-level cause
This behavior is present in v0.80.9 through at least v0.82.7:
safe_output_handler_manager.cjs creates one shared createReviewBuffer() for the entire run and calls submitReview() once.
submit_pr_review.cjs routes every accepted message into that shared buffer.
pr_review_buffer.cjs#setReviewContext only sets context when it is null (first target wins).
pr_review_buffer.cjs#setReviewMetadata overwrites existing metadata and documents "last call wins."
- finalization performs one
pulls.createReview().
The advertised max therefore permits a cardinality the handler cannot preserve.
Live reproduction
Volaris-AI/project-template Software Architect run:
https://github.com/Volaris-AI/project-template/actions/runs/28719559657
The v0.80.9 artifact contains five correctly paired safe-output calls for PRs #4099, #4096, #4094, #4103, and #4106. GitHub received exactly one review: on first target #4099, containing the fifth body intended for #4106:
https://github.com/Volaris-AI/project-template/pull/4099#pullrequestreview-4630267575
A v0.81.6 run reproduces the same first-target/last-body pairing:
https://github.com/Volaris-AI/project-template/actions/runs/29135313394
Expected behavior
Each accepted message must remain paired with its repository, PR, body, event, and inline comments, and each must be finalized exactly once. If batches are not supported, compilation/runtime validation should reject max > 1.
Acceptance criteria
Downstream: Volaris-AI/project-template#4318.
Problem
submit_pull_request_reviewacceptsmax > 1, and scheduled workflows withtarget: "*"can emit multiple calls with differentpull_request_numbervalues. The runtime accepts every call but finalizes only one review:Source-level cause
This behavior is present in v0.80.9 through at least v0.82.7:
safe_output_handler_manager.cjscreates one sharedcreateReviewBuffer()for the entire run and callssubmitReview()once.submit_pr_review.cjsroutes every accepted message into that shared buffer.pr_review_buffer.cjs#setReviewContextonly sets context when it is null (first target wins).pr_review_buffer.cjs#setReviewMetadataoverwrites existing metadata and documents "last call wins."pulls.createReview().The advertised
maxtherefore permits a cardinality the handler cannot preserve.Live reproduction
Volaris-AI/project-template Software Architect run:
https://github.com/Volaris-AI/project-template/actions/runs/28719559657
The v0.80.9 artifact contains five correctly paired safe-output calls for PRs #4099, #4096, #4094, #4103, and #4106. GitHub received exactly one review: on first target #4099, containing the fifth body intended for #4106:
https://github.com/Volaris-AI/project-template/pull/4099#pullrequestreview-4630267575
A v0.81.6 run reproduces the same first-target/last-body pairing:
https://github.com/Volaris-AI/project-template/actions/runs/29135313394
Expected behavior
Each accepted message must remain paired with its repository, PR, body, event, and inline comments, and each must be finalized exactly once. If batches are not supported, compilation/runtime validation should reject
max > 1.Acceptance criteria
submit-pull-request-review.max > 1with an actionable error.Downstream: Volaris-AI/project-template#4318.