Labs · delivery & retries
Accepted is
the beginning.
A request, a response and a delivery are different events. Follow each actor through a virtual timeline.
Simulation — no email is sent
- Application
- Oveyon
- Recipient server
Ready. Step through the first event.
Ready to simulate
Choose Step to advance the virtual clock. No request will be made to an email API.
The full scenario, without animation
The application retries an uncertain HTTP response using the same saved event key. Oveyon deduplicates inside its documented 24-hour window. SMTP delivery is a separate step.
- +0s — Application: Persist the business event. The application saves a synthetic order event and a stable idempotency key before calling the API.
- +1s — Oveyon: Accept the request. The API queues one synthetic message. HTTP 202 means accepted, not delivered.
- +2s — Application: The response is lost. A simulated connection error leaves the application uncertain about acceptance.
- +5s — Application: Retry the same event. The application sends the same payload and saved key; it does not create a new key.
- +6s — Oveyon: Return the original message. Within 24 hours, HTTP 200 duplicate returns the original message identifier. No second message is queued.
- +10s — Recipient server: Accept the message over SMTP. This simulated delivered event means the recipient server accepted it. Inbox placement is not established.
What this does and does not show
Retry scheduling belongs to the application. Oveyon’s API deduplicates a saved key inside its documented 24-hour window. The simulated recipient server eventually accepts the message over SMTP; that does not establish inbox placement.
This is an educational model, not a live message trace or a latency measurement. The virtual timings are illustrative. Exports preserve the simulation warning and actors.
Source: Oveyon API reference — sending, idempotency and delivery states. For a persistent implementation, use the order-confirmation recipe.