feat(core): add redis lock during insertion of event in event table during initial attempt of outgoing webhook delivery

[cookieg13]

Type of Change

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates
• Documentation
• CI/CD

Description

The current implementation of insertion of an event in event table does not handle the case where multiple requests with the same idempotent_event_id might be processed concurrently, leading to multiple unique constraint violation errors in the database.

This was reported by a merchant who was facing high volumes of unique constraint violation errors.

NOTE: this unique constraint log error issue is only applicable for theinitial attempt of outgoing webhook delivery, not for retry attempts

Why does this happen?

1. Multiple requests with the same idempotent_event_id might reach the database at the same time.
2. Each request checks for the event, finds nothing (since it’s not committed yet), and proceeds to insert.
3. The first request succeeds, while the others fail due to the unique constraint on idempotent_event_id.

Solution (Using Redis Lock)
Before querying the database, acquire a lock in Redis for the given idempotent_event_id.
Only one process/thread will hold the lock, preventing others from inserting at the same time.

If a lock is acquired:

• Check if the event already exists in the database.
• If it exists, return early
• Otherwise, insert the event.
• Once done, release the lock

Additional Changes

• This PR modifies the API contract
• This PR modifies the database schema
• This PR modifies application configuration/environment variables

Motivation and Context

How did you test it?

Checklist

• I formatted the code cargo +nightly fmt --all
• I addressed lints thrown by cargo clippy
• I reviewed the submitted code
• I added unit tests for my changes where possible

[semanticdiff-com]

Review changes with  

Changed Files

File	Status
crates/router/src/core/webhooks/outgoing.rs	1% smaller