Skip to content

fix(code-review): preserve in-flight review on merge commit push#2741

Open
alex-alecu wants to merge 5 commits intomainfrom
fix/preserve-review-on-merge-commit
Open

fix(code-review): preserve in-flight review on merge commit push#2741
alex-alecu wants to merge 5 commits intomainfrom
fix/preserve-review-on-merge-commit

Conversation

@alex-alecu
Copy link
Copy Markdown
Contributor

Why

When someone clicked GitHub's "Update branch" button (or merged main into their feature branch), the code review that was already running on their pull request would disappear. It would get cancelled, and no new review would take its place, leaving the PR with nothing. This made it look like our bot just forgot about the PR.

What changed

The webhook that handles new commits on a pull request now checks whether the new commit is a merge commit before it decides to cancel the running review. If it is a merge commit, the webhook quietly walks away and lets the existing review keep running on the real feature commit, where it is useful. Previously the order was reversed — cancel first, then notice it was a merge commit — which threw the valid review away for no reason. The same fix is applied on the GitLab side for merge requests. Small helper functions were extracted so the decision logic is easy to unit test.

How to test

  1. Open a pull request and push a real feature commit. Wait for a code review to start running.
  2. While the review is still running, click "Update branch" on the PR so GitHub creates a merge commit on your branch.
  3. Open the review row in the database (or the Kilo dashboard) and confirm the review's status has not changed to "cancelled" — it should still be running or completed against the earlier feature commit.
  4. Wait for the review to finish and confirm it posted its summary comment on the PR as normal.
  5. Push another feature commit and confirm a fresh review starts for that new commit.

Visual Changes

N/A

Reviewer Notes

The behaviour only changes in one scenario: a synchronize/update webhook whose head is a merge commit and there is already an in-flight review. All other paths (normal pushes, no prior review, opened/reopened events) are unchanged. The merge-commit detection itself was already in the codebase; this PR only moves it earlier in the handler. Downstream logic that picks the incremental review baseline (findPreviousCompletedReview) already filters on status = 'completed' and benefits automatically from not losing the prior review.

When a pull_request.synchronize / merge_request.update event arrives with a merge-commit head (e.g. clicking GitHub's 'Update branch' button), the review was being cancelled before the merge-commit skip check ran, leaving the PR with no active review. Reorder so the merge-commit check runs first and bails out without touching existing reviews. Extract the decision into small pure helpers for unit testing.
@kilo-code-bot
Copy link
Copy Markdown
Contributor

kilo-code-bot Bot commented Apr 23, 2026

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (1 files)
  • apps/web/src/lib/integrations/platforms/github/webhook-handlers/pull-request-handler.ts

Reviewed by gpt-5.4-20260305 · 670,437 tokens

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant