This is the root cause of #4903.
Our Enumerator#next does not appear to be waiting for a second all to perform a second iteration. Because it runs in a separate thread, this causes it to execute in parallel with code that received a previous result. Because of the improper sharing of a write buffer in IOWritableByteChannel, IO.copy_stream to an Enumerator#next-based sink could see a previously-written chunk modified during use.
This issue has been reported against Fiber before, but our Fiber implementation appears to be solid lately. This is strong justification for us to finally eliminate the "second Fiber" we have in Enumerator#next and replace it with one based on our actual Fiber.
This is the root cause of #4903.
Our Enumerator#next does not appear to be waiting for a second all to perform a second iteration. Because it runs in a separate thread, this causes it to execute in parallel with code that received a previous result. Because of the improper sharing of a write buffer in
IOWritableByteChannel,IO.copy_streamto an Enumerator#next-based sink could see a previously-written chunk modified during use.This issue has been reported against Fiber before, but our Fiber implementation appears to be solid lately. This is strong justification for us to finally eliminate the "second Fiber" we have in Enumerator#next and replace it with one based on our actual Fiber.