---
title: "Comment by Hayrullah Kar on \"Out-of-Order Webhooks: Why Deduping Event IDs Isn't Enough\" | Hashnode"
description: "Sorting event types into state and occurrence before writing a handler is the part I will reuse. One edge for fetch-on-notify is a late event for an object that"
url: "https://hashnode.com/posts/webhooks-out-of-order-duplicate-events/6af5465b9b110271f2072a2f/comment/6af6014a8352ea59f168c0e8"
---

[Discussion](https://hashnode.com/posts/webhooks-out-of-order-duplicate-events/6af5465b9b110271f2072a2f)

Comment [Out-of-Order Webhooks: Why Deduping Event IDs Isn't Enough](https://hashnode.com/posts/webhooks-out-of-order-duplicate-events/6af5465b9b110271f2072a2f)

[Hayrullah Kar](https://hashnode.com/@magesheet)

[1d ago](https://hashnode.com/posts/webhooks-out-of-order-duplicate-events/6af5465b9b110271f2072a2f/comment/6af6014a8352ea59f168c0e8)

Sorting event types into state and occurrence before writing a handler is the part I will reuse. One edge for fetch-on-notify is a late event for an object that has since been deleted. Depending on the provider, the fetch may return a 404, and a worker that treats it as a transient error will keep retrying forever. Mapping 'not found' to a deleted state explicitly is worth the extra branch.