Skip to content
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

emit after 'error' #28710

Closed
ronag opened this issue Jul 15, 2019 · 10 comments
Closed

emit after 'error' #28710

ronag opened this issue Jul 15, 2019 · 10 comments
Labels
stream Issues and PRs related to the stream subsystem.

Comments

@ronag
Copy link
Member

ronag commented Jul 15, 2019

I believe the events allowed to be emitted after error should be rather limited.

Based on the test suite I've found the following exceptions:

  • exit, disconnect and close, should be ok.
  • unpipe, maybe ok?

I've fixed some:

#28709
#28708
#28711

Then there are a lot of possible cases that might need fixing:

https://gist.github.com/ronag/b5728ae5db305abaff9955da5b47a5c9

I've found these by updating EventEmitter.prototype.emit with:

  if (this._emittedError) {
    if (!['close', 'exit', 'disconnect'].includes(type)) {
      throw new Error("unexpected event: " + type);
    }
  } else if (type === 'error') {
    this._emittedError = true;
  }

Is this worth to further look into?

@lpinca lpinca added the stream Issues and PRs related to the stream subsystem. label Jul 28, 2019
@rexagod
Copy link
Member

rexagod commented Mar 13, 2020

ping @mcollina

@mcollina
Copy link
Member

emit() is a leaky abstraction: there is nothing stopping anybody to call it and emit an event. The individual cases should be fixed if they do not cause too many regressions.

@rexagod
Copy link
Member

rexagod commented Mar 14, 2020

@ronag I was wondering if it would be okay to allow 'error' events as well? Like the one here. Throwing before all subsequent errors are thrown would prevent those error logs from being shown.

@ronag
Copy link
Member Author

ronag commented Mar 14, 2020

@ronag I was wondering if it would be okay to allow 'error' events as well? Like the one here.

In at least streams we don't want/allow multiple error events.

@rexagod
Copy link
Member

rexagod commented Mar 14, 2020

I see. So are we talking about different behaviour for different modules (subsequent errors not allowed in streams but allowed in crypto (or similar ones))?

@ronag
Copy link
Member Author

ronag commented Mar 14, 2020

I see. So are we talking about different behaviour for different modules (subsequent errors not allowed in streams but allowed in crypto (or similar ones))?

Yea, I guess so. I would rather it would be consistent everywhere but achieving that is a high goal. I think we should start focusing on making it sensible, e.g.

  • No more events after 'close'
  • No more "logic" events after 'error'

etc...

@ronag
Copy link
Member Author

ronag commented Mar 14, 2020

Here is an updated list based on master in case you want to have a go at it https://gist.github.com/ronag/3c4fdf8f73e2671efa8b9456d7bc4746

@ronag

This comment has been minimized.

@ronag
Copy link
Member Author

ronag commented Mar 14, 2020

I think all of the most important issues with post 'error' events have been resolved or has PR's now. Except for:
'close', 'exit', 'disconnect', 'removeListener', 'unpipe', 'error' which I think is ok.

Next step (if any) would be to ensure 'error' is only emitted once and 'close' is always last.

@ronag
Copy link
Member Author

ronag commented Mar 15, 2020

There is work left to do on events after 'close' https://gist.github.com/ronag/c733ec3df54350964f2ead7dec6590e0

ronag added a commit that referenced this issue Mar 17, 2020
PR-URL: #32275
Refs: #28710
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
ronag added a commit that referenced this issue Mar 18, 2020
PR-URL: #32276
Refs: #28710
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
ronag added a commit to nxtedition/node that referenced this issue Mar 19, 2020
PR-URL: nodejs#32275
Refs: nodejs#28710
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Backport-PR-URL: nodejs#32372
MylesBorins pushed a commit that referenced this issue Mar 19, 2020
PR-URL: #32276
Refs: #28710
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
MylesBorins pushed a commit that referenced this issue Mar 24, 2020
PR-URL: #32276
Refs: #28710
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
MylesBorins pushed a commit that referenced this issue Mar 24, 2020
Backport-PR-URL: #32372
PR-URL: #32275
Refs: #28710
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Backport-PR-URL: #32372
MylesBorins pushed a commit that referenced this issue Mar 24, 2020
Backport-PR-URL: #32372
PR-URL: #32275
Refs: #28710
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Backport-PR-URL: #32372
addaleax pushed a commit that referenced this issue Mar 30, 2020
PR-URL: #32277
Refs: #28710
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
addaleax pushed a commit that referenced this issue Mar 30, 2020
PR-URL: #32277
Refs: #28710
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
targos pushed a commit that referenced this issue Apr 22, 2020
PR-URL: #32276
Refs: #28710
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
targos pushed a commit that referenced this issue Apr 22, 2020
PR-URL: #32277
Refs: #28710
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
@ronag ronag closed this as completed Jun 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stream Issues and PRs related to the stream subsystem.
Projects
None yet
Development

No branches or pull requests

4 participants