Closed mathieubergeron closed 3 years ago
Hi Mathieu,
Thanks for the extensive report. I will be looking into this over the weekend.
You're probably quite right this happens due to an error in tee
, but at the same time I'm not sure if this is the best way to achieve what you're trying here...
I'll propose a temporary solution and go after the tee'd error.
Best, M.
Hi, I managed to identify the issue - the raise
method seems to return true
which does stop the stream, but in a strange way: by pushing a true
chunk which in fact does fail. I'm looking into solutions.
Ok, so I did find a problem and a solution was found, however it breaks almost all current tests and cannot be supported in the current interface.
Sadly no elegant workaround is available, but this works:
https://github.com/scramjetorg/scramjet-issue-tests/blob/main/103-whenend/index-workaround.js
In April/May we will be starting work on a new API for Scramjet v5 - v4 interface will be supported as is through a compatibility layer.
Thank you for your investigation! I will be looking forward for v5 then :)
Basics
Hi! I just discovered Scramjet, it looks awesome! I've previously tried highland but ran into some issues regarding how Readable/Writable streams are handled (or had to be handled) on errors - streams were not always closed properly on errors. Moreover, highland seems to be no longer supported. I think Scramjet is a very nice alternative.
So, I'm performing small experiments to understand how Scramjet handles nodejs Readable/Writable streams. More specifically, I want to verify if streams are always properly closed, even on error.
But first, here is a simple test case just to make sure everything works fine:
Note: I'm not sure if using
tee
(orcopy
) instead ofpipe
is the proper way to write the result into a file. But ultimatelly, I want to return a Promise that will resolve on end, or reject as soon as an error occurs. On error, the stream should also stop processing new chunk.pipe
does not allow me to do that.The standard output of that code is:
Obervations/Remarks:
in.txt
does not actually include an empty line at the end)Other then that, all seems great.
Describe the bug
Then I tried to simulate an error:
And faced two (potentially related) issues:
UnhandledPromiseRejectionWarning
Here is the output:
To Reproduce
Would you prefer me to create a public repo with that code? That would not be a problem.
Expected behavior
I guess my first question actually is: am I wrong in thinking that closing the output stream on error is the responsability of scramjet? If I am wrong, how should I handle that properly?
Test case
If possible, please provide an automated test case to include, better yet in a forked scramjet repo in
test/cases
.Let me know if you'd like me to do that.
System
Thanks a lot! Let me know if I can do anything to help.