I think I understand what the problem is; I need to think more about the solution though

@squaremo sorry for the ping, but do you have any update? :-)

@squaremo anything I could do to help moving this forward?

Right I see, the problem is that (as you say) a stream can be added back into newStreams after the initial loop exits, and before the assertion that newStreams is empty. The loop exits because a null chunk has been read (indicating no more chunks); but, 'readable' fires (synchronously, somehow) and the handler for that event appends the stream to newStreams. This breaks the invariant that either all newStreams are exhausted (and removed from that queue), or the downstream is full.

Your fix restores the invariant by putting another loop around the problematic loop, to catch the case where the loop exits but the stream has been added back by the 'readable' event handler.

I think another way to fix it would be to simply remove the special case for when there's a single stream. Since that loop will only exit when !accepting (as before) or the queue is empty, it will have the same effect as the extra loop. It's possible, but harmless, for a stream to be added back to the queue twice.

Sorry for the late response @squaremo, but now updated the PR with your suggestion and it still works for us 👍

@squaremo sorry for the ping, but is there anything else required here?

@squaremo thank you for the support. Could you also release a new version with this fix? That would be wonderful.

@squaremo can you please publish a release with this fix?

Why it had no changelog update?