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.
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?
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.