Which review blocked that merge?

A client says the change was blocked, or says it was approved and still did not land. Tonight, three proofs, in a repository the agency or the client can open. Name the review that blocked that merge: the review id, the state, the commit it names, and the person or app that submitted it. Show a different review on that pull request whose state is not this one. Show another client's repository that does not list this review. If the file only has a comment and the review object was never submitted, write that. A sentence in a chat is not a state.

This is the review on one pull request. It is not the required check. Name the check the merge required is a status conclusion on a commit. A check can pass while a review still requests changes, and a review can approve while a required check is failing. It is not the account that clicked merge. Name who merged their change is that account. A person who approved is not the person who merged, unless the same record says so. It is not the action a workflow runs. Name the action the workflow runs is a uses line. A uses SHA is not a review id. It is not the commit the client is running in production. Name the commit the client is running is the release. A review's commit_id can be an older SHA than the one that shipped.

None of what follows is a finding that this client's review rule is the right one, and none of it is legal advice. The strings below are GitHub's current description of a pull request review. The counts below that are a 2026 conference paper about bot reviews on one public dataset. A public dataset is not this client's private repository. A merge rate in that paper is not the share of this client's pull requests. The docs' sample commit is not this repository's HEAD.

Creating a review and reading a review do not use the same verbs. The create endpoint takes an event of APPROVE, REQUEST_CHANGES, or COMMENT. Three names. Leaving event blank sets the action to PENDING, and a pending review is not submitted, so the response does not include submitted_at. The submit endpoint, on the same guide, says that leaving the event blank returns HTTP 422 and sets the state to PENDING. A blank on create is not a blank on submit. 422 is not 200. The create call's other codes on that page are 200 and 403. APPROVE is not the state APPROVED. REQUEST_CHANGES is not the state CHANGES_REQUESTED. COMMENT is not the state COMMENTED. The event is what you send. The state is what you read back. Do not paste one list over the other. body is required when the event is REQUEST_CHANGES or COMMENT. The page does not say body is required for APPROVE. An empty approval is not an empty change request (GitHub, Pull request reviews).

The sample request is one commit and one line, and neither is a state. commit_id is ecdd80bb57125d7ba9641ffaa4d7d2c19d3f3091. That is one SHA in an example. It is not this pull request's latest commit, and it is not a review id. The event in the sample is REQUEST_CHANGES. The comment sits on path file.md at position 6. 6 is a position in a diff, counted from the first hunk header. The line just below the @@ header is position 1. Position is not a file line number. 6 is not six reviews, and file.md is not a filename in this client's repository. The guide's version header on the examples is 2026-03-10. 2026-03-10 is an API version. It is not a merged date. author_association, on the response schema, is one of COLLABORATOR, CONTRIBUTOR, FIRST_TIMER, FIRST_TIME_CONTRIBUTOR, MANNEQUIN, MEMBER, NONE, or OWNER. Eight names. NONE is an association. It is not a null user. The schema says user can be null. A null user is not the association NONE. OWNER is not a permission you infer from a green button.

Four media types sit on the same endpoint, and they do not return the same body. raw, which is the default, includes body. text includes body_text. html includes body_html. full includes body, body_text, and body_html. Four representations. A client that stored body_html and dropped body has not stored the text the reviewer typed, unless it also stored the raw type. The default is raw. Default is not full. A comment required on a line is a different body from the review's body. The sample has both: a review body, and a comment body on the line. Two strings. Do not delete one because the other already explains the typo.

The paper that counted review states stored four names, and it did not count PENDING. Kowshik Chowdhury, Dipayan Banik, K M Ferdous, and Shazibul Islam Shamim presented it at MSR '26 in Rio de Janeiro on April 13–14, 2026. From the review table they read COMMENTED, APPROVED, CHANGES_REQUESTED, and DISMISSED. Four stored states. COMMENTED is not COMMENT. APPROVED is not APPROVE. CHANGES_REQUESTED is not REQUEST_CHANGES. DISMISSED is not an event on the create page. PENDING, which the docs use for a review that was not submitted, is not in that list of four. The abstract says they analyze 3,109 unique pull requests in the Commented review state, drawn from AIDev's 19,450. The body says the analytical set is 3,177 unique pull requests with at least one review comment, then 3,109 after they drop bots that run workflows rather than review code. 3,177 is not 3,109. The page does not print the difference. Commented, in the body, is 2,456 of those 3,109, which they also call 79.0%. 2,456 is not 3,109. The abstract's phrase, 3,109 in the Commented state, is not the body's sentence. Do not collapse them (Chowdhury, Banik, Ferdous, and Shamim, Code review agents in pull requests).

The body's four buckets are a partition of 3,109, and they are pull requests, not reviews. Commented 2,456 (79.0%). Changes Requested 492 (15.8%). Approved 129 (4.1%). Dismissed 32 (1.0%). 2,456 plus 492 plus 129 plus 32 is 3,109. 79.0 plus 15.8 plus 4.1 plus 1.0 is 99.9, not 100. The page prints both the counts and the percents. Do not repair the percents so they add to 100. Their precedence is Approved, then Dismissed, then Changes Requested, with Commented as the default. A pull request with two Commented reviews and one Approved review is classified Approved. So 2,456 is not a count of reviews whose state string is COMMENTED. It is the pull requests that did not sort into a stronger bucket. 492 is not a count of CHANGES_REQUESTED reviews if another review on the same pull request was Approved. 15.8% is not 4.1%. 32 is not 129.

The comparison they actually compute sits inside the Commented bucket, not inside all 3,109. Only Commented contains pull requests reviewed solely by a code review agent: 281 of 2,456. 281 is not 2,456, and 2,456 is not 3,109. Table 1's five rows add to that 2,456: CRA 281, Mixed(CRA) 117, Mixed 604, Mixed(Human) 278, User 1,176. 281 plus 117 plus 604 plus 278 plus 1,176 is 2,456. It is not 3,109. CRA-only merged 127 of 281, which they call 45.20%, closed 98 (34.88%), and left 56 open (19.93%). 127 plus 98 plus 56 is 281. Human-only merged 804 of 1,176, which they call 68.37%, closed 254 (21.60%), and left 118 open (10.03%). 804 plus 254 plus 118 is 1,176. 68.37 minus 45.20 is the 23.17 percentage points they print. They print 23.17 on the merge rates. They do not print it on the close rates. 34.88 is not 21.60, and the gap between those two is not a number you should write down as theirs. 45.20 is not 68.37. 19.93 is not 10.03.

The other rows are not the headline pair. Mixed(CRA) merged 74 of 117 (63.25%), closed 17 (14.53%), open 26 (22.22%). 74 plus 17 plus 26 is 117. Mixed merged 369 of 604 (61.09%), closed 128 (21.19%), open 107 (17.72%). 369 plus 128 plus 107 is 604. Mixed(Human) merged 189 of 278 (67.99%), closed 41 (14.75%), open 48 (17.27%). 189 plus 41 plus 48 is 278. 67.99 is not 68.37. 63.25 is not 61.09. 14.53 is not 14.75. The chi-squared statistic they print is 83.0319, with p less than 0.001. 83.0319 is not 83%, and it is not 80%. Industry claims in the same paper are a different set. Qodo's survey of 609 developers: 81% see a quality improvement, 69% see a speed improvement, and 80% of pull requests receive no human comments when the agents are on. 81 is not 69. 69 is not 80. 609 is not 3,109. Greptile's 82% who use the tools daily or weekly is not Qodo's 80%. A cited range, human comments addressed 60% of the time and agent comments 0.9% to 19.2%, is not this table. 60% is not 60.2%. 19.2 is not 19.93. 0.9 is not 1.0.

The signal ratios are a cut of 98 closed CRA-only pull requests, not a cut of 281. 59 (60.2%) sit in 0–30%. 14 (14.3%) sit in 31–59%. 7 (7.1%) sit in 60–79%. 18 (18.4%) sit in 80–100%. 59 plus 14 plus 7 plus 18 is 98. 60.2 plus 14.3 plus 7.1 plus 18.4 is 100.0, which is not how the four review-state percents added. 98 is the closed cell. It is not 281, and it is not 127. They name 13 agents. github-advanced-security on 36, Copilot on 24, ellipsis-dev on 11. 36 plus 24 plus 11 is 71, which is not 98, because those three are not the whole set. Copilot's average signal is 19.79%. github-advanced-security's is 27.62%. 19.79 is not 19.93, and 27.62 is not 34.88. codefactor is 0.00%. semgrep-code-getsentry is 100.00% on 1 pull request. 1 is not 13. entelligence is 52.29% on 7. cursor is 43.40% on 5. 43.40 is not 45.20. 52.29 is not 60. 12 of 13 agents, which they call 92.31%, sit under 60%. 92.31 is not 60.2. The abstract's over 400,000 pull requests in two months is the introduction's over 400,000 in less than two months. Two months is not less than two months. Neither figure is 3,109.

Do the three proofs on one real pull request, in the repository the client can open. First, the binding. Copy the review id, the state, the commit_id, and who submitted it. If the state is PENDING, write that submitted_at is absent, and do not tell the client the review blocked the merge. If the state is COMMENTED, write COMMENTED. Do not upgrade it to CHANGES_REQUESTED because the sentence sounded strict. If the only record is an event you meant to send, and the object was never stored, write that. Do not infer APPROVED because a sample request exists. Second, the other review. A different review on the same pull request, with a different state, is not this one. A paper's bucket is not that second review. If you cannot show a review that is not this state, you have a counter, not a record. Third, the other repository. Another client's list does not contain this review id. If the only list is a shared bot account and you cannot say which client it reviewed, write that.

Three moves feel like the proof and are a second problem. Treating REQUEST_CHANGES in a script as the state you will read back. The docs already use a different string on the way out. Quoting 45.20% or 15.8% because one of them looks like this pull request. 45.20% is 127 of 281 in someone else's Commented bucket. 15.8% is 492 of 3,109 under a precedence rule. Neither is the state on this review. Asking a model whether the change was approved. The model will pick a plausible verb from the three events. It will not open the review. A required check you have not named is still name the check the merge required. A green check is not a state.

The path is ordinary when an admin can open one item and say what decision was stored, without opening the next item as the way to prove it. FeedDrop includes an admin panel that reviews, approves, features, and publishes one piece of content. The shape that matters here is one item you can point at, distinct from the next item. That case is not a pull-request ledger. Nothing in the description is a headcount, a duration, or a result figure. If the only control on the screen publishes every item, you do not have this proof. You have a feed.

There is a version of this merge where hiring the path is the wrong purchase. The work is not sold under the agency's name, so there is no repository yet. The client asked to meet the people who will build, and the document in front of you is a term sheet. The criteria for that choice sit on the page written for a top SaaS development company. That page is criteria. It does not rank anyone, including us. The room only has a slide, or the buyer only wants a template of a review. A template is not the state on this commit. Or the buyer wants a legal opinion about whether a particular review was required. Hire the lawyer.

When the change is real and the review is not on a screen you can open, the missing object is specific. The review id, the state, the commit, a second review that is not that state, and another repository that does not list it. A white label software development partner that expects this will put the repository where the client can read the review, before the first merge, because a sentence on a laptop you do not hold is not a state you can name. One that can only paste a screenshot into chat is telling you who holds the review. Where the next slice is one capability and the acceptance sentence names the review, an AI integration sprint is the shape that can require the three proofs as the definition of done. Where you are not sure which repository the current engagement merges into, a two-week AI readiness assessment maps the systems. The findings are yours. They are not a promise that 23.17 points of this client's pull requests were lost to a bot, and they are not a rate.

The refund a charge got, and the batch a request joined, are different objects: which refund did that charge get? and which batch did that request join?. Do not record either on this page. A refund status is not a review state. A batch id is not a commit SHA.

Before you tell the client the merge was blocked, do the three proofs and write the state. Name the review, the state, and the commit, or write that the review was not stored. Show a different review that is not that state. Show another repository that does not hold it. Do not send REQUEST_CHANGES and then read it back as if the string had not changed, and do not borrow 15.8% from a corpus this repository is not in. The comment is what someone typed. The state is the page you can defend.