`timeout`

Fails any single pull that takes longer than limit with a TimeoutException.

FxAsyncIterable<A> timeoutAsync<A>(Duration limit, FxAsyncIterable<A> iterable) FxAsync<T> FxAsync<T>.timeout(Duration limit) // chain (async)

Lecture

A pipeline is only as responsive as its slowest await. timeout(limit) puts a bound on that: each pull — the work of producing one item, however many upstream operators it passes through — must finish within limit, or the pull fails with a TimeoutException. Fast items are untouched; the operator adds no delay of its own.

Pull-model semantics, worth being precise about: the limit measures demand-to-item time — from the moment downstream asks to the moment the item arrives. It does not measure gaps between items (there are none without demand) and it does not bound the whole pipeline (that is Future.timeout on the terminal: fxAsync(…).toList().timeout(…)). RxDart's timeout watches inter-event gaps on a push stream — same name, measured from the other side.

fxdart extension (no FxTS counterpart). Parallel-safe: under concurrent(n) each overlapping pull carries its own timer, so n slow-ish items that overlap still pass individually. Pair with retry — timeout turns "hanging" into "failing", and retry turns "failing" into "try again".

Demo 1 · Catching the stall

Demo 2 · Per pull, not per pipeline

Try it yourself

Exercise: bound the slow feed, then recover.

Related: retry — what to do after the timeout fires · concurrent — overlapping pulls time out independently · typed errors — catching the TimeoutException as a value