-
Notifications
You must be signed in to change notification settings - Fork 30.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error [ERR_MULTIPLE_CALLBACK]: Callback called multiple times in 16.8.0 with Stream & pipeline #39923
Comments
I think that this is a duplicate of #39535 |
You can't both return a promise (async) and call the callback. |
Sorry, this example does not really show why I made _final async. In the real world I may be doing something that involves an asynchronous operation, such as invoking a database's commit in my _final() implementation. I need the async to allow me use await with this call. If I remove the async I cannot use await. How would I code a _final() implementation that needs to wait for an asynchronous operation to complete before invoking the callback, do I simply have to revert to a 'then' based model ? |
You should either do callback based implementation or promise based. Mixing the two is usually a bad idea. |
If I am implementing a stream I am forced to invoke the callback since that is what the specification defines, I don't have any choice in the matter do I ?. Are you saying that if I am implementing any of the methods defined by the streams API I have to totally abandon the clean coding model offered by async/await. Can I still use promise.then().catch() safely or do I really have to resort to 'callback hell' |
You don’t have to call the callback if you return a promise. |
Ah, interesting let me experiment... |
Isn't there something missing from the documentation then ? If I understand correctly this should specify that the method can either execute the callback or return a promise https://nodejs.org/api/stream.html#writable_finalcallback |
And it looks like this is the behavior for _final, but not _write, _transform, etc.. Shouldn't this be the new default for all stream methods ? edit: sorry I just realized that the discussion is actually here #39535 |
Version
16.8.0
Platform
Microsoft Windows NT 10.0.19043.0 x64
Subsystem
Streams pipeline
What steps will reproduce the bug?
Here's a simple testcase
How often does it reproduce? Is there a required condition?
All the time
What is the expected behavior?
In 16.4.2 the error is not raised
What do you see instead?
In 16.8.0. this fails with
Additional information
The change in behavoir seems to arise as a result of a code change to the callback's added by pipeline
In 16.4.2 the callback code generated by node streams pipeline is
Where as in 16.8.0 it is
So the code attached by pipeline has clearly changed and is resulting in a change of behavior causing an error to be raised where no error was raised before.
However I am not clear why node thinks the callback has been called twice. As far as I can tell I am only invoking it once.
As I see it there are 4 possibilities:
Node is correct, the callback is being invoked twice and my code is incorrect, in which case any hints as to what needs to changed would be much appreciated.
Node has always (incorrectly) caused the callback to be executed twice. However as a result of the code changes between 16.4.2 and 16.8 this is now causing an error to be raised.
There is a new problem in Node 16.8 that is causing the callback to be invoked twice.
The code added to detect multiple invocations of the callback is incorrect
The text was updated successfully, but these errors were encountered: