Id of a review request


#1

Short version: review request objects do not include an id in webhooks or API endpoints. This makes syncing difficult.

Long version:

My application requires syncing historical review requests and new review requests in real-time using webhooks.

Since there’s no canonical “id” or identifier shared between the webhooks and API, there is no way to identify whether a review request that came in through a webhook is the same review request as one returned in the events API, and vice versa. This makes is almost impossible to prevent duplicates when syncing historical data using the API in combination with syncing real-time webhooks.

Is there any reference or id in the webhooks payload or issue events API or another API endpoint that I am missing that could solve this problem? How come review requests do not have an id or some other permanent identifier?


Review request IDs
#2

Hi @abinoda so it looks like you also reached out to GitHub support and have been responded to.

I’m going to drop the response from @izuzak in here in case anyone else comes along with this question.


Is there any reference or id in the webhooks payload or issue events API or another API endpoint that I am missing that could solve this problem?

No, not currently.

How come review requests do not have an id or some other permanent identifier?

I believe it’s because there’s nothing to attach the id to. Notice that there’s no separate review request object – it’s just a reference to a user or a team object. A user or a team have their own IDs but the review request doesn’t because there’s no object to attach it to.

For example, when you fetch a list of review requests for a pull request (https://developer.github.com/v3/pulls/review_requests/#list-review-requests), you get back this:

{
  "users": [ { ... } ],
  "teams": [ { ... } ]
}

There’s really no place to put the id field here since “users” and “teams” are just lists of user and team objects which have their own ids. Where did you expect such an id to show up here?

Webhooks deliveries never have IDs of their own since the delivery itself is not a permanent object and also is different from events in the issue events API.

That said, I understand how this would be useful for the task you described, so I’ll pass your feedback to the team to consider for the future, but I don’t expect any changes in the near future.

I wish I had better news for you, but I don’t. Still, I hope this answers your question, and let me know if there’s anything else.


#3