Topics covering webhook creation & management, event handling, Pub/Sub, and Eventbridge, in Shopify apps.
Hi there,
Delete and disconnect webhook requests don't include any time related information such as event timestamp, create/update timestamp etc. When they are missed the retries can cause issues on the application.
Is there any plan to add a field such as retry-number to the http headers when sending webhooks so that we can identify that this is a retry webhook and be careful to process it multiple times. An example can be found on here under Graceful retries section.
Hey @Mete
so that we can identify that this is a retry webhook and be careful to process it multiple times.
Can you please provide an example of how you might use this?
Scott | Developer Advocate @ Shopify
@SBD_ wrote:Hey @Mete
so that we can identify that this is a retry webhook and be careful to process it multiple times.
Can you please provide an example of how you might use this?
Hi @SBD_,
There could be outage in apps. We could miss a delete event. When Shopify retries sending a delete webhook an hour later, that could be problematic because there is no identifier for us to understand if this is something new or retry. Assume we get inventory_levels/connect before the retry of inventory_levels/disconnect which will end up losing an existing inventory level for a location.
We can solve this problem for create/update webhooks because they generally contain created_at, updated_at fields. But there is no time related information in delete, disconnect webhooks. We need either an event timestamp or a retry-number in webhook so that we can process it accurately.
Just want to add that I think this is a pretty great idea. Would help us debug actions from webhooks that might execute partially successfully.
Want to see it in action? Check out our demo store.