Do webhook events contain a timestamp? How can I know if an event has been emitted before another one?

[guizmaii]

Select Topic Area

Question

Body

Hi 🙂

I'm implementing a GitHub App.
I'd like to receive the "installations" webhook events to maintain the state of my app installations.
I see that an installation can have four states: created, deleted, suspended, and unsuspended.

Because this is event-based, to update my DB I need to be sure of the ordering of the events before updating the state of an installation in my DB.

If I receive or process the events in the incorrect order, the result could be that the state of the installation in my DB would be incoherent with the state of the installation in GitHub.

Let's take an example.
Let's say a user first suspend my app in its account and then unsuspends it.
I'll receive a suspended event and an unsuspended event.
If for some (networking, congestion, concurrency, etc.) reason, I receive/process the unsuspended event first, then receive/process the suspended event second, I want to be able to see that the suspended event I'm processing in second was emitted before the unsuspended so that I can ignore it.

I can't find this information/timestamp in the GitHub webhooks doc nor in the payloads I receive from the webhook.

Do the events emitted (or the request headers) contain this information?

Thanks for your help,
Jules

[faisalnazir7]

[guizmaii]

Hey @faisalnazir7

Thanks for your help 🙂

Sequential processing with a queue

If I have 2 instances of my app running on 2 different servers, each of them behind a reverse proxy load balancing the traffic to each instance in a round-robin way, there's no guarantee that the event 1 received by the app instance 1 is put in the queue before the event 2 received by the app instance 2 is put in the queue.
My app instance 1 can be busy doing something else, for example, which would delay enough the delivery of the event 1 so that it's put in the queue after the event 2.

If some network congestion happens on the route of event 1, I'm not even sure that the event 1 will be received by the reverse proxy before the event 2

I'm sorry but I'm not convinced your proposal is a correct/robust solution

Event versioning

Same issue as above. How can I ensure that my versioning is the correct one?
As there's no guarantee I receive the events in any order, I might incorrectly version the events

Handle idempotent updates

This has nothing to do with my issue

Retry and error handling

This has nothing to do with my issue either

[guizmaii]

Hey @nirav-gajera,

Thanks for your help 🙂

The created_at timestamp is also included in the request headers of the webhook. The header is called X-GitHub-Event-Timestamp

I'm sorry but I don't find this header.
Here's an example of event emitted by GitHub. There's apparently no such header 😕

Yes, the events emitted by GitHub contain the information you need to determine the order in which they were received. The installation event payload includes a created_at timestamp that indicates the time the installation was created or updated

Well, indeed it seems that the installation updated_at (and not created_at) field could be used as the event timestamp.
Thanks for your help!

[guizmaii]

If anyone reads this one day, the "solution" I've found above isn't really a solution because in some events there's no created_at nor updated_at field. Basically, no date at all in the event, which means that we cannot always derive a timestamp for the event from its content, which means that some events are not timestamped at all.

More details, see: https://twitter.com/guizmaii/status/1691048850318823424?s=20

[imconnorngl]

@guizmaii I understand that this is a long way down the road and you may not even mind, but this is the post that came up when I went looking for the timestamp of an event with GitHub Webhook and thought it's worth tossing my findings here.

When looking at all the available headers, I spotted that X-GitHub-Delivery was a UUID, and from my other research it seems like that is unique to each request! So it got me wondering what version of UUID is this using?

Not sure how common knowledge this is, but a UUIDV1 contains a timestamp and lucky for us X-GitHub-Delivery is a UUIDV1.

So I was able to derive a timestamp from your event and it seems like it matches up!

const uuidTime = function (uuid) {
  // Split the UUID string into an array
  const uuidArr = uuid.split('-');
  const timeStr = uuidArr[2].substring(1) + uuidArr[1] + uuidArr[0];

  // Convert the time string to an integer, adjusting for the UUID epoch
  const uuidTime = parseInt(timeStr, 16) - 122192928000000000;
  const uuidMillis = Math.floor(uuidTime / 10000);

  return new Date(uuidMillis);
};

// Convert X-GitHub-Delivery header to Event Timestamp
const date = uuidTime("0d2dd4d0-2c4f-11ee-8d9f-85919bcb71e8");
console.log(date);

[3dbrows]

@imconnorngl The years went by and eventually someone saw this comment (me) and thought it a brilliant solution to the problem of knowing when GitHub raised a webhook event. I would happily buy you a meal deal from a Greggs of your choice, such is my esteem here. Thank you.