# Review the code between persistence and acknowledgement

The receiver's success response creates a delivery promise. Check that no process crash can leave acknowledged work without a durable recovery path.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Locate the exact success boundary

Read the handler and identify the statement after which it returns the provider-appropriate success response. Determine what has been committed by that point.

An in-memory queue, unawaited promise or process-local task is not durable acceptance. A successful enqueue call needs the guarantees of the actual queue and client configuration.

Review error handling so a failed storage operation cannot fall through to a success response.

## Inspect the database-to-queue gap

If the receiver stores an inbox row and separately publishes a queue notification, determine what happens when only one action succeeds.

A polling worker or transactional outbox can provide a recovery path where appropriate. The design should not depend on both independent calls always succeeding together.

Test the actual failure boundary rather than only mocking both dependencies as successful.

## Check duplicate identity and processing

Verify the uniqueness scope and atomic enforcement for repeated receipt. Do not confuse resource identity with event identity.

Then inspect the worker's effect boundary. A processed flag written before the effect can lose work, while one written after an unprotected external effect can allow duplication after a crash.

Use the operation's transactional or idempotent recovery mechanism and document unknown outcomes explicitly.

## Require a crash test

Interrupt the process after durable receipt but before acknowledgement, and after the effect but before final recording. Verify the resulting retries and business state.

Include multiple instances so local coordination cannot make the test pass accidentally.

Approve the receiver when its success response has a clear durable meaning and processing can recover from each interruption. The handler can remain short without leaving the most important work outside a reliable boundary.

## Crash between receipt and business processing

Use a concrete crash boundary in the review: the receiver verifies the webhook, records its event identity and returns success, but the worker stops before applying the business update. The event must remain recoverable from durable state. If success is returned before that state exists, the provider may believe delivery is complete while the application has lost the work.

Run a separate duplicate delivery after the update succeeds. The same event should lead to one application outcome, while a different event concerning the same resource must still be considered under its own semantics.

## Sources

- [GitHub: webhook best practices](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks)