The modbus-rs transport-level retry knobs this package deliberately does
not expose.
They are withheld rather than merely discouraged because enabling them is
never the right call under this design:
They retry below the Effect boundary. A failure they paper over never
reaches the policy, the circuit breaker, or the logs — the caller sees one
slow success instead of several failures and a recovery, and any
caller-side timeout is measuring inflated time.
They reconnect. Upstream re-establishes the link inline and replays
in-flight requests after it, which races the one supervisor fiber that is
supposed to own reconnection for the whole transport.
They multiply. Neither layer knows about the other, so attempt counts
compound and the two backoff curves interleave.
retryDelayMs is flat and unjittered, the collision pattern that
RetryPolicies.serial() exists to break up; retryBackoffStrategy is
documented upstream as inert, so setting it does nothing at all.
Use the retry and reconnect options on TransportResilienceOptions
instead. Callers who genuinely need frame-level resends can construct a raw
modbus-rs client directly, where the trade-off is explicit.
The
modbus-rstransport-level retry knobs this package deliberately does not expose.They are withheld rather than merely discouraged because enabling them is never the right call under this design:
retryDelayMsis flat and unjittered, the collision pattern thatRetryPolicies.serial()exists to break up;retryBackoffStrategyis documented upstream as inert, so setting it does nothing at all.Use the
retryandreconnectoptions on TransportResilienceOptions instead. Callers who genuinely need frame-level resends can construct a rawmodbus-rsclient directly, where the trade-off is explicit.