Ahh yes, thanks

My original thought was to use a buffered channel to mark the removals to be handled in the receive go routine. The motivation being to avoid a locking data structure on the receive path. However, a flood of stream closing which fill up the buffer would likely make that solution unworkable. I'll try to consider other lock free ways we could handle this, but we should get this change in.

@dmcgowan thanks.
Streaming is a great project, the logic in it is so complex that it took me a lot of time to understand it, I admire your ability to come up with this stuff :)

How did you notice the issue by the way? It would be great if we can write some autometed way to check that this part won't have leaks in future.

I added the test log locally. If we want to cover it by unit test, we need to save streams to serverConn in order to check it at some point later. But it is expected that there will be more modifications.