Retry Handler Fails When Request Has a Body about undici HOT 5 CLOSED

I think the fix here is to avoid the use of an AsyncIterable in fetch if the full body was specified. We can save quite a bit of overhead.

from undici.

This is indeed tricky. On one hand, state altering verbs should not be automatically retried, on the other hand, it's a pretty common case.

from undici.

It might be better to just scope this to the safe methods only GET, HEAD, and OPTIONS instead of the idempotent ones.

Tho the issue seems to root the AsyncIterable that is made out of fetch.
As the AsyncIterable has been already consumed at its first request, when the RetryHandler attempts a new request, the content-length mismatch surfaces as undici fails to iterate over the body because it was already consumed.

Not sure what will be the course of action here, I'd say that maybe the handler can make a best attempt to detect specific bodies (Stream, AsyncIterable) and clone them and attempt to free them after successful request. Just will add the overhead of duplicated bodies

from undici.

FWIW I tested directly with Streams and are handled properly by the RetryHandler, but facing similar issue to as per fetch with AsyncIterator (once consumed it does not loop). So this is definitely something that the handler might need to be aware of

from undici.

Streams should not be possible to handle correctly unless they were 0 length.

from undici.