[FEATURE] Propagate cancellation about client-zip

[Touffy]

ReadableFromIter consumes the upstream async iterable only if you pull from the ReadableStream it makes. Before that, it's a chain of async generators. So if you feed downloadZip from a lazy generator, it should never trigger more than one download ahead of its output (or a few downloads if you properly optimize the source for high-latency small files as implied in your other issue).

It's not perfect, because all the generators in the chain will be left hanging and it won't cancel a fetch that's already started.

Your suggestion (handling cancel on the output stream) solves the first problem (cleanly ending all the async generators).

However, to solve the second problem (aborting a fetch), we'd need an AbortSignal. When you call fetch, you can give it an optional abort signal (should be the same signal for all the requests feeding one zip). If you also give that signal's controller to downloadZip, then, upon cancellation of the output stream, we can trigger the signal.

Both are easy to implement.

[cprussin]

Even if we don't have an AbortSignal handled by the library, it's easy enough to wrap a fetch in a stream and handle the abort signal in the stream's cancel callback, so I'd definitely start there.

I'd be happy to put in a PR for this when I get some time. Will be a few days / weeks as this isn't the highest priority issue for me right now but I will get back to it when I'm able to!

[Touffy]

If your source starts multiple downloads (because you want to buffer a few Responses ahead, as discussed elsewhere) but the output stream is cancelled, then the read stream for the file currently being processed would be cancelled.

However, the streams for the other Responses in the source haven't been consumed by downloadZip yet, and will never be. downloadZip shouldn't greedily consume all the source just to call cancel on each stream, that could easily backfire (triggering more requests that necessary, for example).

So the request cancellation needs to be handled at the source. If the source is a generator or a stream, you can detect that it's been cancelled itself and trigger the AbortSignal (which is better than cancelling Response streams, because it will also cancel requests that don't have a resolved Response yet).

So, in fact, you shouldn't even need to give your signal to downloadZip. If downloadZip propagates output stream cancellation all the way to its source, the source can do whatever needs to be done to clean up any pending task.

To sum it up, I will definitely propagate output cancellation to the input stream. Anything more than that, once again, "isn't my problem".

[Touffy]

Output stream cancellation now throws an error upstream (versions 1.6.1 and 2.4.1).

[Touffy]

Sorry, I underestimated the work necessary to propagate errors through async generators. I'm reopening this issue until the fix is published (it's already working in my test environment, but I had to do something that seems too complicated and I'm looking for a simpler solution).

[Touffy]

Fixed for real this time !