7
votes

How should you handle the fact that events received via webhooks can be received in random order ?

For instance, given the following ordered event:

  • A: invoiceitem.created (with quantity of 1)
  • B: invoiceitem.updated (with quantity going from 1 to 3)
  • C: invoiceitem.updated (with quantity going from 3 to 2)

How do you make sure receiving C-A-B does not result in corrupted data (ie with a quantity of 2 instead of 3)?

You could reject the webhook if the previous_attributes in Event#data do not correspond to the current state, but then you are stuck if your local model was updated already, as you will never find yourself in the state expected by the webhook.

Or you can just use treat any webhook as a hint to retrieve and update an object. You just disregard the data sent by the webhook and always retrieve it. Even if you receive events ordered as update/delete/create it should work, as update would in fact create the object, delete would delete it, and create would fail to retrieve the object and do nothing. But it feels like a waste of resources to retrieve data each time when the webhook offers it as event data.

This question was asked before but the answers don't cover the above solutions.

Thanks

1
I would go with the latter. Use the event to know that I should fetch the latest state of the object and trust that latest statekoopajah
You might want to consider moving this extended discussion to the existing question you link to, rather than having a very similar original question.dmulter
Also, another approach to consider is using the created common field to all Stripe webhook events. You could implement a small holding area for incoming requests and process them in correct date order.dmulter
@dmulter I did. Mentioned the post to show I did my homework. Posted because the original question body is ambiguous regarding its goal: the OP’s final question is a request for a node module. Plus I’ve had answers to old questions ignored despite being actual answers and feared a question as an answer would not spark much of a debate.Arnaud

1 Answers

0
votes

If your application is sensitive to changes like this that can occur close in time, you really should just use the event as a signal to retrieve the object, as @koopajah noted in their comment. That's the only way to ensure you have the latest state.