Which comment did that review leave?

A client says the review never mentioned the bug, or says the note on the diff was someone else's. Tonight, three proofs, in a repository the agency or the client can open. Name the comment that review left: the comment id, the line, and the commit. If the review stored no comment, write that, and do not invent a sentence to fill the hole. Show a different comment whose id, or whose line, is not this one. Show another client's repository that does not list this comment. If any of the three needs the person who clicked the review button, you have not named the comment. You have a memory of a sentence and a guess.

This is the comment on one review. It is not the branch. Which branch did that pull target? is the base ref and the head ref. A pull can target the right branch while this comment sits on a commit that is no longer the head. It is not the review that blocked the merge. Which review blocked that merge? is the review that held the pull. A blocking review can exist while this comment's body is a different sentence, and a comment can exist on a review that did not block. It is not the label. Which label did that issue carry? is the name and the color on an issue. A label is not a line on a diff. It is not the tax on an invoice, and it is not the assistant on a thread. Those are different objects, and they are not this id.

None of what follows is a count of this client's reviews, and none of it is legal advice. The fields below are one host's current description of a pull-request review comment, and the samples are not one history. The counts below that are a study of other people's Java repositories. An id on an example is not a census of your pulls. A paper that scored unanswered comments in public projects cannot name the comment on the review you opened tonight. They do tell you which numbers people mix up when they try to sound precise about a note they have not opened.

GitHub's current create example sends a body and does not send an id. The body is Great stuff! 12 characters. The commit id is 6dcb09b5b57875f334f61aebed695e2e4193db5e. 40 characters. The path is file1.txt. 9 characters. start_line is 1. line is 2. start_side and side are both RIGHT. 2 minus 1 is 1. The request does not send a comment id, a review id, or an in_reply_to. The page says position is closing down, and that position counts lines down from the first @@ hunk header, where the line just below that header is position 1. line 2 is not that definition of position, even when a subtraction happens to equal 1. per_page defaults to 30 and the maximum is 100. sort is created, updated, or created_at. 3 names. created is not the string created_at. direction is asc or desc. 2 names. The recommended API version header on that page is 2026-03-10. 10 characters. A version string is not a comment id (GitHub, REST API endpoints for pull request review comments).

The response sample that GitHub Enterprise Server 3.12 still prints is a different page, and it does not match the URL it is sitting in. The url ends in comments/1. The id field is 10. 1 is not 10. pull_request_review_id is 42. 42 is not 10. node_id is MDI0OlB1bGxSZXF1ZXN0UmV2aWV3Q29tbWVudDEw. 40 characters, the same length as the commit id, and not the same string. diff_hunk begins @@ -16,33 +16,40. 33 is not 40. 16 in the hunk is not line 2, and the 40 on the new side of the hunk is the commit id's length only by coincidence. path is file1.txt again. position is 1. original_position is 4. 4 minus 1 is 3. The subtraction that made 1 out of line and start_line is not this 3. commit_id is the same 40-character SHA the create request sends. original_commit_id is 9c48853fa3dc5c1c3d6f1f1cd1f2743e72652840. Also 40 characters, and not the same SHA. in_reply_to_id is 8. 8 is not 10. The create request did not send 8. A sample that stores a reply id is not the request that omitted one (GitHub, Review comments on Enterprise Server 3.12).

The same 3.12 sample keeps two clocks and a body that a later example on that page does not send. created_at and updated_at are both 2011-04-14T16:00:49Z, so the gap is 0. user.login is octocat. 7 characters. user.id is 1. 1 is the number in the url, and it is not the comment id. body is Great stuff! again, 12 characters. The html url ends in discussion-diff-1. That trailing 1 is not id 10. author_association is NONE. The enum has 8 names: COLLABORATOR, CONTRIBUTOR, FIRST_TIMER, FIRST_TIME_CONTRIBUTOR, MANNEQUIN, MEMBER, NONE, and OWNER. 8 names is the same integer as in_reply_to_id, and it is not that field. start_line is 1, original_start_line is 1, line is 2, original_line is 2, start_side is RIGHT, side is RIGHT. The printed sample does not include subject_type. The attribute list allows line or file. 2 names, the same count as side, and not a value you may invent onto this object. A reply example on that page sends the body I like this too! 15 characters. The response printed under it is still Great stuff! and still id 10. 15 is not 12. Do not treat the request sentence and the response sentence as one comment because they share a page.

The current page's other limits are a different scale from a study of unanswered notes. The list endpoint returns an array. The 3.12 list example contains 1 object. 1 is not the default per_page of 30, and 1 is not the maximum of 100, and 1 is not id 10. Four media types are named: raw, text, html, and full. 4 is original_position, and it is not a media type. The enterprise example's API version header is 2022-11-28. Also 10 characters, and not 2026-03-10. Two version strings of the same length are not one version. Author association NONE is one of 8. The sample user id is 1, which is not an association. A comment you can defend is the id, the line, and the commit on this repository. A hunk header is not that id.

The study people quote when they want a rate of ignored review comments did not open this pull. Yike Li, Yuxia Zhang, Qunhong Zeng, Lin Shi, Xin Tan, Tao Wang, Yanjie Jiang, and Hui Liu annotate review comments in Java projects on GitHub. They stratified-sampled 80 projects and aimed at 10 pull requests each. 80 times 10 is 800. Some small repositories had fewer than 10 commented pull requests, so they annotated 760. 800 minus 760 is 40. The page does not print 40. Those 760 pull requests hold 2,104 review comments. 57 of the 760 have at least one no-response comment, and they print 7.5%. 57 divided by 760 is 0.075 exactly, which is 7.5%. The 92 no-response comments are 4.4% of 2,104 in their results sentence. 92 divided by 2,104 is 0.04373, which rounds to 4.4%. That match is real. A different sentence says the 92 were identified from 712 comments. 92 divided by 712 is 0.1292, which is 12.9%, not 4.4%. The page does not print 12.9. Do not swap the denominators (Li, Zhang, Zeng, Shi, Tan, Wang, Jiang, and Liu, An empirical study of overlooked code review comments).

The same paper's categories do not agree with themselves about how many types there are. The abstract says two main categories with seven subcategories, and that review inquiry has four while pull-request management has three. 4 plus 3 is 7. That addition matches the abstract. A later section says they categorize eight types, then lists the same four inquiry subcategories and the same three management subcategories. 4 plus 3 is still 7. 8 is not 7. The page does not print a seventh-plus-one that would make eight. They say the 92 comments range from one to twelve per pull request. 12 is not 7, and 12 is not 8. Survey invitations went to 544 of 1,359 developers they had identified. 45 responses came back, printed as 8.3%. 45 divided by 544 is 0.0827, which rounds to 8.3%. 28 of the 45 had been in open source for 1 to 10 years, printed as 62.2%. 28 divided by 45 is 0.6222, which rounds to 62.2%. 11 had been involved for over 10 years, and 6 for less than a year. 28 plus 11 plus 6 is 45. That addition matches. 43 of 45 are described as male. The page does not print 95.6, which is what 43 divided by 45 would be, times 100.

The medians and the extra repository are a different scale from a comment id. They exclude 7 open pull requests from the duration check. 760 minus 7 is 753. The page prints 753. The median duration of those 753 is 3 days. The 57 pull requests that contain a no-response comment have a median of 20 days. 20 is not 3. On elasticsearch they sampled 100 pull requests and 382 review comments, and 15 of the 100 contained at least one no-response comment, printed as 15%. 15 divided by 100 is 0.15. 15 is not 7.5. 382 divided by 100 is 3.82 comments per pull request. The median on the 760 is 2. 3.82 is not 2. They also write that 64.4% of reviewers reported encountering a no-response comment in the past year. 64.4 is not 7.5, and 64.4 is not 15. 33 of the 45 respondents offered a suggestion. 33 is not 45. None of these cells is comment id 10, and none of them is the body Great stuff!

Do the three proofs on one real review, in the repository that actually holds it. First, the binding. Copy the comment id, the line, and the commit. If the review has no review comments, write that. Do not infer id 10 because a sample prints it, and do not infer Great stuff! because a sample body prints it. If the url's trailing number and the id field disagree, write both, the way comments/1 and id 10 disagree on the sample page. If the request body and the stored body disagree, write both. 15 characters is not 12. Second, the other comment. A different comment, with a different id or a different line, is not this one. in_reply_to_id 8 and id 10 are that shape on the sample, and they are still a sample. A count of 2,104 other people's comments is not that second comment. If you cannot show a comment that is not this one, you have a counter, not a record. Third, the other repository. A repository that belongs to another client does not list this comment id. If the only list is a single shared organization and you cannot say whose pull it is, write that. A tenant you cannot name is the finding. It is not a reason to tell the client the note was on line 2.

Three moves feel like the proof and are a second problem. Pasting a sentence into the pull because the review comment list was empty, and then describing the missing id as a cleanup. Quoting 7.5% because it looks precise, while the review you were asked about is one row, and the study that printed 7.5% had already used two different denominators for the same 92. Asking a model which comment was left. The model will produce a plausible sentence. It will not open the pull. A branch you have not kept, while the client is arguing about which ref the note targeted, is which branch did that pull target?. Opening that screen does not name the comment.

The path is ordinary when an operator can open one client's repository without opening the next client's repository as the way to prove it. Cove is one operator experience consolidated from systems that had been separate. The shape that matters here is one client's repository you can point at, distinct from the next client's repository. That case is not a review-comment ledger. Nothing in the description is a headcount, a duration, or a result figure. If the only control on the screen shows a merged pull and will not name a comment id, you do not have this proof. You have a status.

There is a version of this afternoon where taking the work is the wrong purchase. The work is not sold under the agency's name. The client asked to meet the builders. The room only has a slide. The buyer only wants a template. Or the buyer wants a legal opinion about whether a sentence on a diff is a promise. A white label software development partner can work under the agency's domain and the agency's tools. That page is the offer. It does not name this comment, and it does not turn 7.5 into a line number.

When the review is real and the repository cannot name the comment, the missing object is specific. The comment id, the line, and the commit, a different comment that is not that one, and another client's repository that does not list it. A white label software development partner that expects this will put the repository in the client's organization, or in the agency's, before the first review, because a note that lives only on a laptop you do not hold is not a comment you can name. One that can only paste a sentence into chat is telling you who holds the diff. Where the next slice is one capability and the acceptance sentence names the comment id, 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 reviews in, a two-week AI readiness assessment maps the systems. The findings are yours. They are not a promise that 7.5% of this client's pulls are unanswered, and they are not id 10.

The tax an invoice added, and the assistant a thread named, are different objects: which tax did that invoice add? and which assistant did that thread name?. Do not record either on this page. A percentage is not a line. An assistant id is not a commit. The role an invite granted is a different object: which role did that invite grant?. Do not record it here. A role name is not a line.

Before you tell the client the review left that note, do the three proofs and write the id. Name the comment, the line, and the commit, or write that the review stored no comment. Show a different comment that is not that one. Show another repository that does not hold it. Do not paste a sample sentence onto an empty list, and do not ask a model which of the notes it was. A paper can tell you what it counted on other people's pulls, including the type count that does not match its own addition. The binding is the comment you can defend.