Githawk: Pull request review threads GQL broken

[rnystrom]

This has been broken on GitHub's end for almost 2 months. Been trying to get an answer here but it's not going well.

Probably have to play around w/ other ways to get PR review threads and contents. Bummer.

[rnystrom]

Got a response, tho its basically "known bug, no ETA".

[BasThomas]

It’s better than nothing at least :)

[Sherlouk]

How has this still not been fixed 🙄 😞

The fact this isn't a feature really annoys me, more so because there's nothing we can do about it 😕

[rnystrom]

I know I’m losing my mind not having these. Gonna try to hack a fix today... 😭

_{Sent with GitHawk}

[Sherlouk]

I've already spent an hour trying to find every alternative I could, even looking at the v3 API previews 😅 Couldn't find anything

Short of loading a WKWebView and using JavaScript to extract it 😂

[rnystrom]

Lol ya, its totally broken. Updated w/ a reply:

https://platform.github.community/t/pullrequestreviewthread-no-longer-showing-up-in-timeline-for-prs/2755/17

Hoping we can get some clarification on what is going on here. Its _impossible_ to get PR review threaded comments atm w/ the GQL API. Huge disappointment.

[Sherlouk]

Okay so I don't think they're going to fix it... so I've found an alternative. @rnystrom

https://api.github.com/repos/rnystrom/GitHawk/pulls/704/comments?access_token=revoked
https://github.com/rnystrom/GitHawk/pull/704

The above endpoint returns an array of comments, in chronological order. It appears to only include comments from a review (it doesn't include the root comment, or other comments in the feed from my testing). The nodes can contain a "in_reply_to_id" which is always the first comment in a "discussion".

So in the above PR I left a comment "Not sure if whatever rule is causing this..." the ID of which is 146309348. The other three comments in that "discussion" have the "in_reply_to_id" field pointing to the same ID. We obviously then use the time to work out the order of messages!

The same endpoint also has "pull_request_review_id" which can be linked back to the response we already have from the GQL response (By either decoding the id value in the same way we have for comments, or using the deprecated databaseId field). This means we can tie multiple discussions to a single review.

To confirm:

• Current GQL response gives us a "Review ID"
• Using the endpoint above we can get all the comments
  
  
  
  • We then need to filter that response down to only the comments with a pull_request_review_id of the review.
  
  
  • Using the original data, we then want to create a new subset which is anything with in_reply_to_id as the ID of the comments we just filtered. (This gives us a dictionary of discussions)
  
  

[BasThomas]

@Sherlouk, I love you.

That is all.

_{Sent with GitHawk}

[Sherlouk]

I needed some loving today 😔

It's amazing what having a 3hr nap at 5pm does to your brain 🤔

Only took me a month

[rnystrom]

Awesome. So we need to send a second request, but we only need to do it for PRs. I guess paged items might be a little tricky, but maybe we just worry about that later?

[Sherlouk]

Yeah PRs with a lot of review comments will need paging, haven't the foggiest how we would achieve that though (the endpoint is pageable, but wouldn't know when to trigger additional requests)

There's no way that I can see to find out how many comments a review has either, so no way to detect that 🤷‍♂️

I think yeah leave paging for now, get the first 25 or what ever default response is

[Sherlouk]

@rnystrom I'm removing this from the 1.12 milestone as we have got the functionality in now to see review threads.

I'd opt to leave this issue open though so we can further track the original bug with the GQL API and in hopes that they will, eventually, maybe, probably not, fix it!