Skip to content

Console class ignores ignoreErrors on Node.js v14.3.0 #33628

Description

@exoego

What steps will reproduce the bug?

  1. Create a repro.js which contents is below:
ws = require('fs').createWriteStream('./foo.log');
ws.destroy();
c = new require('console').Console({
    stdout: ws,
    stderr: ws,
    ignoreErrors: false
});
c.log("should fail");
  1. Run ndoe repro.js

How often does it reproduce? Is there a required condition?

Every time it reproduces on the above environment with the above procedure.

What is the expected behavior?

Invoking c.log should throw error, since the underlying streams are already destroyed, like below:

events.js:287
      throw er; // Unhandled 'error' event
      ^

Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed

Note) The expected errors are thrown on Node.js v12.16.3 and v10.20.1.

What do you see instead?

No errors thrown, and script runs succesfully.
It seems that Console class ignores ignorErrors option.

Activity

  1. changed the title [-]Console class do not respect ignoreErrors on Node.js[/-] [+]Console class do not respect ignoreErrors on Node.js v14.3.0[/+] on May 29, 2020
  2. changed the title [-]Console class do not respect ignoreErrors on Node.js v14.3.0[/-] [+]Console class ignores `ignoreErrors` on Node.js v14.3.0[/+] on May 29, 2020
  3. added
    streamIssues and PRs related to Node.js streams.
    on May 29, 2020
  4. BridgeAR commented on May 29, 2020

    @BridgeAR
    Member

    @ronag PTAL

  5. XadillaX commented on May 29, 2020

    @XadillaX
    Contributor

    It seems because of

    ws = require('fs').createWriteStream('./foo.log');
    ws.destroy();
    ws.write('foo');

    do not throw error any more.

  6. ronag commented on May 29, 2020

    @ronag
    Member

    This is expected. You can't error an already destroyed stream. #29197

  7. exoego commented on May 29, 2020

    @exoego
    ContributorAuthor

    So, errors thrown on Node.js v12 & v10 were bug, that was fixed somewhere on v13/v14 ?

  8. XadillaX commented on May 29, 2020

    @XadillaX
    Contributor

    But I think it's a breaking change.

  9. ronag commented on May 29, 2020

    @ronag
    Member

    But I think it's a breaking change.

    Yes, it was labeled as semver-major.

  10. ronag commented on May 29, 2020

    @ronag
    Member

    So, errors thrown on Node.js v12 & v10 were bug, that was fixed somewhere on v13/v14 ?

    Not sure exactly what you mean. A lot of things fall under that description. But this specific case wasn't a bug per se, but it was ambiguous/undefined behavior that we changed to make it predictable. There were also other problems this caused that the change resolved.

    It was a very long discussion as you can notice from the PR and not at decision taken lightly.

  11. exoego commented on May 29, 2020

    @exoego
    ContributorAuthor

    Thanks for quick response 👍

    I saw there was long disucssion in #29197, and the change seems reasonable to me.
    My understanding is that the error I saw on Node.js v12 were due to ambiguous/undefined hehaviors.

    I am closing this issue as "as-designed" or similar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    streamIssues and PRs related to Node.js streams.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions