2 ms·

> Once we await that callback to resolve, then the buffered data from before that point is known to be flushed. This is not true IME. Just more likely. See my

by 3np 2y ago

> Once we await that callback to resolve, then the buffered data from before that point is known to be flushed. This is not true IME. Just more likely. See my comment here: https://news.ycombinator.com/item?id=41829905 https://news.ycombinator.com/item?id=41829905 > If I wait for finish, a background “thread” can extend the process lifetime by continuing to log. Can you not address this by calling .end() on the stream? https://nodejs.org/api/stream.html#writableendchunk-encoding-callback https://nodejs.org/api/stream.html#writableendchunk-encoding... > Our rule: if you want the process to wait for your async work to complete, then `await` it. In general I very much agree. In this specific case, though, the awaits are just buying you a bit more time to race the buffer which is why they appear to help. The "flush" will not wait for completion before exiting the process. Maybe also worth keeping in mind that even if this would be working, stuff like this has historically changed breakingly a few times between major Node releases. If you're relying on unspecified behavior you're obviously in darker waters.

throwitaway1123 2y ago
> See my comment here: https://news.ycombinator.com/item?id=41829905 https://news.ycombinator.com/item?id=41829905 Your comment isn't equivalent to the original code. Your one liner is doing this: `process.stdout.write('')` Jitl's example is doing this: `new Promise(resolve => stream.write("", resolve))` He's passing in a promise resolver as the callback to stream.write (this is basically a `util.promisify` version of the writable.write chunk callback). If the data is written in order (which it should be), then I don't see how the `stream.write` promise could resolve before prior data is flushed. The documentation says: "The writable.write() method writes some data to the stream, and calls the supplied callback once the data has been fully handled". [1] [1] https://nodejs.org/api/stream.html#writablewritechunk-encoding-callback https://nodejs.org/api/stream.html#writablewritechunk-encodi...
- jitl 2y ago
  It's so easy to miss a tiny but important detail when working with or discussing Node streams and come out the other side bamboozled by bugs. This whole thread exemplifies why I tell people to stay as far away from streams as possible. Though in the case of stdout/stderr we can't avoid it.
  - 3np 2y ago
    > It's so easy to miss a tiny but important detail when working with or discussing Node streams and come out the other side bamboozled by bugs. This whole thread exemplifies why I tell people to stay as far away from streams as possible 100%. Case-in-point: After coming back I realize that indeed I did overlook the callback/promise making the difference for the write call. Sorry for spreading lies!

by 3np 2y ago

throwitaway1123 2y ago

> See my comment here: https://news.ycombinator.com/item?id=41829905 https://news.ycombinator.com/item?id=41829905 Your comment isn't equivalent to the original code. Your one liner is doing this: `process.stdout.write('')` Jitl's example is doing this: `new Promise(resolve => stream.write("", resolve))` He's passing in a promise resolver as the callback to stream.write (this is basically a `util.promisify` version of the writable.write chunk callback). If the data is written in order (which it should be), then I don't see how the `stream.write` promise could resolve before prior data is flushed. The documentation says: "The writable.write() method writes some data to the stream, and calls the supplied callback once the data has been fully handled". [1] [1] https://nodejs.org/api/stream.html#writablewritechunk-encoding-callback https://nodejs.org/api/stream.html#writablewritechunk-encodi...

jitl 2y ago
It's so easy to miss a tiny but important detail when working with or discussing Node streams and come out the other side bamboozled by bugs. This whole thread exemplifies why I tell people to stay as far away from streams as possible. Though in the case of stdout/stderr we can't avoid it.
- 3np 2y ago
  > It's so easy to miss a tiny but important detail when working with or discussing Node streams and come out the other side bamboozled by bugs. This whole thread exemplifies why I tell people to stay as far away from streams as possible 100%. Case-in-point: After coming back I realize that indeed I did overlook the callback/promise making the difference for the write call. Sorry for spreading lies!