AshDispatch.Transport.Retry (AshDispatch v0.8.4)
View SourceHow a failed receipt is retried, per transport.
This exists because the answer used to live in two places:
Workers.RetryFailedDeliveries (the cron) and Changes.EnqueueRetryJob
(the :retry, :reopen and :send_now actions). Both carried the same
three branches, so a transport added to one but not the other would be
retried by the cron and not by the admin UI, or the other way round. The
list now exists once.
The strategies
{:worker, module}— enqueue an Oban job. The module must exportnew_for_receipt/1.{:direct, module}— delivery is synchronous and retried inline. The module must exportretry_from_receipt/1.:unsupported— the transport has no way back.
:unsupported is not harmless
A receipt whose transport has no strategy still goes through :retry, which
increments retry_count, and then lands back in :failed when the enqueue
fails. Five cron passes later it is :failed_permanent — without having been
resent even once. That is exactly what happened to :sms until 0.8.2.
Summary
Functions
Retries a receipt according to its transport's strategy.
True if the transport can be retried.
The transports that can be retried. Mainly for error messages and tests.
The strategy for a transport.
Functions
Retries a receipt according to its transport's strategy.
For the worker path only. The direct path ({:direct, _}) is handled by the
caller, because the cron and the admin actions need different answers back:
the cron wants to know the receipt is already fully handled so it can skip
its own status update, the actions want a job id to store.
True if the transport can be retried.
@spec retryable_transports() :: [atom()]
The transports that can be retried. Mainly for error messages and tests.
The strategy for a transport.