Fix multiple read attempts in fetch client

[srikrsna-buf]

Fix multiple read attempts in fetch client. I caught this while working on connectrpc/examples-es#1075. The fix similar to how we read the iterable:

connect-es/packages/connect/src/protocol/universal-fetch.ts

Lines 129 to 130 in 51470eb

	const it = iterable[Symbol.asyncIterator]();
	return new ReadableStream<Uint8Array>(<UnderlyingSource<Uint8Array>>{

This also fixes the underlying issue of pipe calling the iterator twice.

[timostamm]

From connectrpc/examples-es#1075:

Using the fetch client from connect, the client for server steaming throws an error at the very end of the steam with: Invalid state: ReadableStream is locked.

Seems like some code is calling [Symbol.asyncIterator]() twice. If this is in our code base, it would be great to understand where this happens, and avoid it. Did you take a look at how the duplicate call occurs?

[srikrsna-buf]

Seems like some code is calling [Symbol.asyncIterator]() twice. If this is in our code base, it would be great to understand where this happens, and avoid it. Did you take a look at how the duplicate call occurs?

It seems to be this line:

connect-es/packages/connect/src/protocol/async-iterable.ts

Lines 596 to 599 in e0bffba

	// cleanup any allocated resources.
	source[Symbol.asyncIterator]()
	.return?.()
	.catch(() => {

in pipe.

[timostamm]

Yeah, looks like that line in async-iterable.ts would do it. I believe we should avoid that.

If you iterate over an Array or Map, you would expect a second iteration to restart from the first entry. Under the hood, [Symbol.iterator] is called once per iteration. I would expect [Symbol.asyncIterator] to have the same semantics. By calling it twice for what is effectively a single iteration, we dip out toes into undefined behavior.