Rails Inbox Jobs: Review Retry and Duplicate Handling

Retrying an inbox-processing job should recover unfinished work without repeating a completed business action. Review message identity, parsing status and downstream side effects independently. A single green job status cannot establish all three outcomes.

Revdoku, listed in the Ruby on Rails catalogue observed on October 3, 2026, describes inbound email storage for AI agents with logs, versions and locks. Those listed features suggest useful evaluation questions; they do not establish the exact queue adapter, retry policy or guarantees of its implementation.

Give ingestion a durable identity

Start with the product's definition of one received message. Provider delivery identifiers, message headers and attachment hashes can answer different questions. Do not choose a deduplication rule merely because one field happens to be easy to read.

Ask how the pipeline distinguishes another delivery of the same message from a genuinely new message containing similar text. A customer's repeated request may deserve a new conversation entry even when its wording is identical.

Keep the received record separate from processing attempts. Several attempts can belong to one accepted message, and each should have its own timing, error and completion evidence. This structure makes operational retries understandable without inflating the message count.

Specify the retry policy explicitly

Rails Active Job documentation describes retry handling and execution controls. Their availability is not evidence that a particular application configured safe retries. The team still needs to decide which failures are temporary, which require correction and when processing should stop.

For a proposed acceptance test, interrupt a disposable parsing job before completion and then retry it through the documented operation. Inspect whether the original remains available and whether only one current parsed result becomes visible.

Use a separate scenario for a permanently unsupported attachment. Repeating the same failure indefinitely should not be the recovery strategy. A clear failed state with a reason can be more useful than an apparently active queue that never finishes.

Protect the boundary after parsing

The dangerous duplicate often occurs after an agent has acted, not while text is being extracted. If a downstream workflow creates a ticket or sends a response, give that business operation its own identity and confirmation record.

Do not use a worker lock as the only proof that an action happened once. A worker can stop after an external service accepts an action but before local completion is recorded. Recovery needs a way to reconcile that uncertain outcome.

Keep an approval linked to the exact proposed action and evidence version. Reprocessing a message should not silently reuse an old approval for changed content or a different recipient.

Make the operator's decision small

A useful support view shows the accepted message, latest parsing result, previous attempts and downstream action state. It should make the difference between retry parsing and retry sending obvious.

Practice recovery with synthetic messages and a sandbox destination. Record the expected number of message records, derived outputs and external actions before starting. These are suggested acceptance tests, not reported results for Revdoku.

For the underlying evidence structure, see the inbound email provenance guide. Reliable replay depends on knowing which source and processing version each attempt used.