Outbound webhook deliveries lack an idempotency key — at-least-once dispatch duplicates

[cybermax4200]

Why this matters now: User webhooks receive duplicateProofStatus events on every retry/re-delivery, which downstream integrations must not have to dedupe themselves.

Problem / What: sendWebhook (notificationDispatchService.ts:11-41) POSTs the same payload on every dispatch with no Idempotency-Key/dedupe header. BullMQ retries (configured with attempts: 3) and the outbox redelivery both re-POST. Even after fixing #6, any legitimate redelivery produces a duplicate webhook.

Key Challenges: Generating a stable idempotency key (e.g., outboxId + channel + attempt-bucket) that survives retries but allows genuine re-sends after a permanent failure reset; coordinating with webhook consumers.

Acceptance Criteria:

• Repeated dispatch of the same outbox row to the same webhook sends an Idempotency-Key that is stable across retries and changes only on a deliberate re-send.
• A consumer replaying with the same key is a no-op (documented expectation).

Relevant files/functions: src/services/notificationDispatchService.ts:11-41, src/workers/notificationWorker.ts:54-73.

Out of scope: Webhook signature verification (separate concern).

Labels: advanced, reliability, bug

[DatabyPrisca]

Please can you give me this issue? I have experience in doing this and I am sure to bring value to your team.

[Flames4fun]

Hey @cybermax4200, I’d like to pick this up if you’re okay assigning it to me.

This is very close to reliability work I’ve already shipped in Free-Way: #55 added bounded timeout/failure behavior around outbound providers, and #70 added HTTP-level compatibility regression coverage using deterministic local dispatch paths. Both were merged, and I enjoyed working on exactly this kind of boundary where retry behavior has to remain predictable for downstream consumers.

For this issue, my initial approach would be to treat the idempotency key as the identity of the logical webhook delivery, not the individual BullMQ attempt. That should let retries reuse the same key while an intentional re-send gets a fresh delivery identity, with tests covering both cases.

I’d like to take this one because it’s small enough to stay reviewable but still fixes a real delivery contract. Optimistically, I expect I could have the PR ready in around 1–3 hours, assuming I don’t uncover a broader outbox-state dependency while tracing the flow.

[udeachudivine-spec]

Hi maintainer i would like to apply for this issue, i would Claim comment: Will add an idempotency key to outbound webhook deliveries — generate a unique key per event/attempt, include it in the payload/header (e.g. Idempotency-Key), and dedupe on the receiving/logging side so retries from at-least-once dispatch don't create duplicates. Please assign — GitHub: udeachudivine-spec.

[grantfox-oss]

🦊 GrantFox — @udeachudivine-spec has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #59)
2. Your PR will be reviewed by the ecotask-network maintainers

Good luck! Track your progress on GrantFox.