Repository navigation
gardener: Answer review threads in place and explain failures (Gardener 0.1.11) - #198
Conversation
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| Propose the steps in this order: the commit, the replies, the resolves, the summary. A plan may | ||
| have at most 40 steps, so answer at most 15 threads in one round, and say in the summary that more | ||
| remain for the next one. Nothing |
There was a problem hiding this comment.
馃煛 Excess review threads remain unanswered
With more than 15 threads, pr-review-fix leaves some unanswered and promises another round. Only a submitted review starts that round, so the remaining threads wait for another reviewer action.
Learn more
The task runs on a submitted pull request review, not on its own commit, thread replies, or summary comment. Its 15-thread limit leaves excess threads pending, but no further task run is scheduled just because work remains. The three-round limit also means a large initial review cannot all be answered through automatic rounds without new submitted reviews.
Example: A review contains 16 unresolved threads. The first run replies to 15 and posts a summary saying one remains for the next round. No next run starts, so the sixteenth thread receives no response.
Recommended fix: Arrange a bounded follow-up run for remaining threads, or remove the artificial per-round truncation while adjusting the effect budget safely. Keep the round limit and termination conditions consistent with the maximum review size.
Was this helpful? React with 馃憤 or 馃憥 to provide feedback.
| request's `reviewThreads(first: 100)` with each thread's `id`, `isResolved`, `path`, `line`, | ||
| its `comments(first: 50)` with `databaseId`, author login and body, and its latest comment as | ||
| `latest: comments(last: 1)`. Answer every unresolved thread, not only those from the review that |
There was a problem hiding this comment.
馃煛 Later review threads go unseen
When a pull request has over 100 review threads, reviewThreads(first: 100) excludes later threads. Unresolved findings beyond that page receive no answer.
Learn more
GitHub's reviewThreads is a paginated connection. Requesting only its first 100 nodes can hide unanswered threads even when most of those 100 have already been resolved. The task never tells the model to request pageInfo or use after to fetch later pages.
Example: A pull request has 100 resolved threads followed by one new unresolved thread. The query returns only the resolved ones, so the new finding is never inspected or answered.
Recommended fix: Request pageInfo { hasNextPage endCursor } and paginate reviewThreads until every page has been checked. Then apply any per-round answer limit to the unresolved threads collected across all pages.
Was this helpful? React with 馃憤 or 馃憥 to provide feedback.
| started this run: a round can absorb a review whose own run GitHub dropped. Skip a thread whose | ||
| latest comment is by `github-actions[bot]` and contains `<!-- gardener-operation:`: you already | ||
| answered it, and nobody has replied since. Also treat the body of the |
There was a problem hiding this comment.
馃煛 Thread replies do not trigger follow-up
When a reviewer replies to an answered thread without submitting a review, pr-review-fix never runs again. Its workflow trigger listens only for submitted reviews, leaving that reply unattended.
Learn more
The skip condition waits for a new comment after Gardener's last answer. But a reply to a review thread can arrive as a pull_request_review_comment.created event without a new pull_request_review.submitted event. The workflow trigger subscribes only to the latter, so the changed latest-comment state alone cannot run the task.
Example: Gardener declines a thread and replies. A maintainer adds a standalone review-thread reply showing a reproduction. No new review is submitted; the task never checks the reply.
Recommended fix: Add a suitably guarded review-comment trigger for follow-up replies and ensure Gardener's own replies cannot loop, or direct maintainers to submit a new review when they want a reply reconsidered.
Was this helpful? React with 馃憤 or 馃憥 to provide feedback.
commit: |
1 participant
Gardener now answers each review finding in its own thread on its pull requests, and resolves only the threads its commit fixed. Each run also writes a GitHub job summary that explains failures in plain words.
pr-review-fixchangesOther changes from the upgrade to 0.1.11
actions/checkout,upload-artifactanddownload-artifacton Node 24, so the Node 20 deprecation warnings are gone.gardener:generatepoints at@scuffi/gardener@0.1.11.mention-replyandtriagekeep the same bundle hashes.Tested on a demo repository first
As before, a maintainer approves CI on commits Gardener makes with the workflow token.