Question
Moleculer Redis transporter interaction: default retry limit handling
Dev Moss
0 reputation · 13 Oct 2022, 09:47 UTC
74.3K views
Loading…
0 reputation · 13 Oct 2022, 09:47 UTC
The goal is to clarify how Moleculer’s Redis transporter behaves when an action throws an error and no custom retries is defined. The framework’s documentation states that the default retry policy is indefinite, which may lead to continuous re‑delivery attempts and uncertain back‑pressure semantics under sustained failure conditions.
Constraints include the absence of a user‑specified retry limit, reliance on the transporter’s internal retry loop, and the potential for resource exhaustion if failures persist. Understanding whether the transporter applies any implicit delay, circuit‑breaker interaction, or termination condition is essential for designing resilient services.
Does Moleculer continue retrying the failed action indefinitely until the process is stopped?
What back‑pressure or delay mechanisms, if any, are applied during continuous retries?
How can developers observe or constrain this retry behavior without modifying each action’s options?
33775 reputation · 13 Oct 2022, 20:32 UTC
The Moleculer Redis transporter does **not** perform retries itself. Retry handling is delegated to the ServiceBroker’s request‑retry system.
moleculer{ retries: 5, factor: 2, minTimeout: 100, maxTimeout: 10000, randomize: true }.retry property, the broker’s global retry settings are used for every call made via the Redis transporter.console.log(broker.options.retry);undefined, the defaults above apply.Retrying request... in the broker’s logs.const broker = new ServiceBroker({ retry: { retries: 3, factor: 2, minTimeout: 200, maxTimeout: 5000 } });retry field in the action definition.If you need to know whether any custom retry value has already been applied to the broker, please confirm the current value of broker.options.retry (or the result of broker.getOptions()). This detail determines whether the default described above is actually in effect.
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 13 Oct 2022, 13:22 UTC
When the Redis transporter’s retries option is omitted or set to 0, it does not attempt any re‑delivery; the message is either acknowledged or rejected and the ServiceBroker’s request‑retry mechanism (configured via broker.options.retry) takes over. If you explicitly set retries: N on the transporter, the transporter will re‑publish the failed message up to N times, applying only the optional retryDelay (or a fixed delay) between attempts—no exponential back‑off or jitter is added unless you configure it yourself. Thus, to see transporter‑level retries you must set that option and enable DEBUG logs for the RETRY category; otherwise the broker’s retry logs (Retrying request…) are what you observe.