このページはまだ翻訳されていないため、英語で表示されます。 翻訳に参加する

RxDart vs FxDart › #28 · Retry with growing backoff

Retry with growing backoff

FxDart wins async

• fx
• retry

Requirement

The rate service is unavailable exactly twice, then serves. Retry with growing backoff — wait 40 ms after the first failure, 80 ms after the second — with a budget of three attempts. Print the payload, the attempt count, and the recorded backoff sequence (recorded when each wait is chosen, so the output is deterministic). Both versions must print the lines shown under Expected output.

rates: EUR 0.85, GBP 0.74, JPY 148.20
attempts: 3
backoff: 40ms, 80ms

Side by side

Why they differ

Backoff is where the one-call symmetry of plain retry breaks. RxDart's retryWhen is a meta-stream protocol: for every error, your factory must return a notifier stream — emit a value to trigger the retry, emit an error to give up. So "wait 40 ms, then 80 ms" becomes mapping each failure to an Rx.timer stream, and because the factory only sees one error at a time, both the failure count and the attempt budget live in mutable variables outside the operator. It works, and it is maximally general — but you are hand-assembling a retry loop out of streams.

FxDart treats backoff as what it is: a number that depends on how many times you have failed. The delay hook on retry receives the failure count (1, 2, …) and returns a Duration — the whole policy is one expression, and the budget is the same attempts argument as before. Nothing about waiting between attempts requires a stream, and the pull side never pretends it does.

Verdict FxDart, on concept count: one hook versus a notifier-stream factory, an external counter, and a timer stream per failure.