Some webhook events lack identifiers, while the same events via grahpql API do not.

When receiving events via the Github Webhook, many of them contain “id” and “node_id” fields. Comparing to the GraphQL api, “id” is equivelant to “databaseId” and “node_id” is equivelant to “id”. That’s great. Knowing that, I can correlate data received via the webhooks with data that I’ve quiered via the graphql endpoint. 

However, some events received via the webhooks contain no identifying information at all. For example, an issues assigned event simply references the issue, the assignee, and the sender (the user doing the assigning). Since a user can assign/unassign another user repeatedly, there is nothing that uniquely identifies that event for a given issue. If there was atleast an official timestamp sent with the event, we could haphazardly correlate it with data received via the graphql endpoint, but there isn’t even that. 

So basically what I’ll be forced to do is when receiving these types of events via the webhook, I then have to requiry the issue/PR timeline via the graphql endpoint in order to retreive the necessary data. That defeats much of the purpose of the webhook in the first place. 

I agree with you that adding timestamps to the webhooks could improve the workflow tremendously.

Regarding your specific problem, which data is missing in the webhook event that forces you to query via graphQL endpoint?

Also note that you have a updated_at field on the issue webhook that you can maybe use as the lacking timestamp of the webhook.

The actual identifying information is missing. There is neither an “id”, “databaseId”, or “node_id” when received via the webhook. However when I query the same event via graphql, it has a unique identifier. 

You are correct in that the issue.updated_at seems to represent the timestamp of these events. I eventually realized that, and as far as I’m aware the combination of an issue, assignee, and timestamp allows you to safely determine the Assigned event in question. However, it would be quicker/easier, and far more confidence inspiring if an actual identifier were provided. 

Well, In the issue webhooks that I receive there is the issue field on which you have a node_id identifier:

{
  "action": "opened",
  "issue": {
    ...
    "id": 608232264,
    "node_id": "MDU6SXNzdWU2MDgyMzIyNjQ=",
    "number": 1,
    "title": "TITLE",
    "user": {
      ...
    },
    "labels": [

    ],
    "state": "open",
    "locked": false,
    "assignee": null,
    "assignees": [
    ],
    "milestone": null,
    "comments": 0,
    "created_at": "2020-04-28T11:11:02Z",
    "updated_at": "2020-04-28T11:11:02Z",
    "closed_at": null,
    "author_association": "CONTRIBUTOR",
    "body": "BODY"
  },
  "repository": {
    ...
  },
  "organization": {
    ...
  },
  "sender": {
    ...
  }
}

Could you share the payload of the issue webhook you are receiving?

I’m not referring to the issue, I’m referring to the event itself. For instance, if you assign a user to an issue, the webhook merely delivers an “assigned” event which references the issue, the sender (assigner), and the assignee. There is no unique identifier given for the event specifically.

Contrast that with the GraphQL API, if you query the timelineitems of an issue/PR you will receive the entire history of events for it, and each one contains a unique identifier.