Inline Pull Request Comments: Loss of Critical Functionality in 2.0 API

Bitbucket Development Bitbucket Cloud
1

Noticed a couple basic functionalities from v1 are missing in the 2.0 pull request comment posting APIs, and they are currently undocumented so I was curious if there are workarounds or if support will be added to v2 before the sunset at the end of this month.

Here’s what the request body looks like using the 1.0 API:
POST /repositories/{accountname}/{repo_slug}/pullrequests/{pullrequestnumber}/comments

{
    "username": "tutorials",
    "pull_request_id": 672,
    "comment_id": 14356,
    "display_name": "tutorials",
    "parent_id": null,
    "deleted": false,
    "utc_last_updated": "2012-08-12 20:04:38+00:00",
    "filename_hash": null,
    "base_rev": "174eecac678c",
    "filename": null,
    "content": "This is yet another comment",
    "content_rendered": "<p>This is yet another comment</p>\n",
    "user_avatar_url": "https://secure.gravatar.com/avatar/0bc5bd490000b8e63c35c0f54e667b9e?d=identicon&s=32",
    "line_from": null,
    "line_to": null,
    "dest_rev": "101f16a95c13",
    "utc_created_on": "2012-08-12 20:04:38+00:00",
    "anchor": "a18fd07465b5",
    "is_spam": false
}

And here are the issues I’m running into using the 2.0 API:

  1. Using v2 it’s currently impossible to post a reply comment based on a parent comment’s ID (see parent_id in the request above). Therefore, you can never create a reply tree using the API, you can only keep adding top-level comments when posting to a specific line within a pull request.

  2. It’s also currently impossible to specify a commit sha when posting an inline comment (see base_rev, dest_rev, and anchor in the request above). You can only set a to/from line key, which I assume just selects either the base sha or current head sha, but this won’t function properly throughout the lifecycle of a pull request since the underlying code changes commit to commit.

These restrictions essentially render any application that is handling pull request interactions via the API useless, so I’m hopeful that either they will be added to 2.0 before deprecation, or the 1.0 APIs will continue to be maintained until this functionality is supported using 2.0. Any guidance here will prove helpful! Thanks.

2

Hi @patrick1! Thanks for the questions.

  1. Fortunately, it is possible to post a reply comment in the 2.0 API. It’s a little unintuitive, but the way to do it in 2.0 is to specify {"parent": {"id": 14356}} instead of {"parent_id": 14356}. I acknowledge that our docs could do a better job explaining this.
  2. We are definitely aware of this issue and we’re working on a backwards-compatible solution to allow clients of the 2.0 API to specify revisions. That said, I should point out (in case you weren’t aware) that we do “adjust” the location of existing comments when changes are pushed: for example, if you leave a comment on line 5 of a file, and then later the author pushes a commit that adds a line above your comment, your comment will thereafter appear on line 6. But of course there is still the possibility of a race condition where an API client loads a diff, then the author pushes changes, and then the API client posts a comment with outdated line numbers. As I said, we are aware of that, and I will gladly update this post when we’ve shipped a solution!
1 Like