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

Dealing with async errors during _read() #29584

Closed
ronag opened this issue Sep 16, 2019 · 3 comments
Closed

Dealing with async errors during _read() #29584

ronag opened this issue Sep 16, 2019 · 3 comments
Labels
stream Issues and PRs related to the stream subsystem.

Comments

@ronag
Copy link
Member

ronag commented Sep 16, 2019

I feel like there is something missing in the streams _read API for implementors.

Basically the current state of things is that stream implementors need to implement async error handling something like this:

_read (n) {
  doAsyncRead(n, (err, buf) => {
    if (err) {
      if (this._readableState.autoDestroy) {
        this.destroy(err)
      } else {
        this.emit('error', err)
      }
    } else {
      this.push(buf)
    }
  })
}

There are some problems with this:

  1. Most stream implementors don't do this and simply don't bother to conform to the autoDestroy option and either destroy() or emit('error', err), which one they choose is mostly unclear and undocumented.
  2. Even when conforming you either have to access the _readableState object or add a flag based on the options sent to the Readable super.

I'm not quite sure how to resolve this. I can think of a few ways:

  1. Add a cb to _read that can be invoked with an error and would internally call the errorOrDestroy method.
  2. Make the errorOrDestroy util directly accessible for stream implementors and document it somehow.
  3. Leave as is and clarify in documentation how to handle this scenario (preferable without _readableState).
  4. Deprecate autoDestroy and make it true by default.
  5. Document that autoDestroy is for stream implementors only and not for stream consumers.
@Fishrock123 Fishrock123 added the stream Issues and PRs related to the stream subsystem. label Sep 22, 2019
@Fishrock123
Copy link
Contributor

I ran into these kinds of issues for Fishrock123/bob#35 as well.

Add a cb to _read that can be invoked with an error and would internally call the errorOrDestroy method.

I find it quite odd that _read doesn't have an error callback, honestly. That being said, I don't have a clear idea what answer is really good here.

@Fishrock123 Fishrock123 changed the title _read async error Dealing with async errors during _read() Sep 22, 2019
@ronag
Copy link
Member Author

ronag commented Sep 22, 2019

@Fishrock123 I went with this #29653. Works well as long as autoDestroy: true.

Trott pushed a commit that referenced this issue Sep 27, 2019
Errors should be propagated through destroy(err). Anything else
is basically undefined behaviour.

PR-URL: #29653
Refs: #29584
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
targos pushed a commit that referenced this issue Oct 1, 2019
Errors should be propagated through destroy(err). Anything else
is basically undefined behaviour.

PR-URL: #29653
Refs: #29584
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
@ronag
Copy link
Member Author

ronag commented Oct 6, 2019

We want people to use destroy(err). I think we updated the docs in some PR.

@ronag ronag closed this as completed Oct 6, 2019
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

2 participants