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

Handle stream error in StandaloneConnector.js #1236

Closed
wants to merge 5 commits into from
Closed

Handle stream error in StandaloneConnector.js #1236

wants to merge 5 commits into from

Conversation

peteraw77
Copy link

Solution proposed by @OPScorp in #1209 . Solves #1235 as well. I'm not sure why he didn't PR this himself but it was helpful for myself and others so I would like to get it merged.

@AVVS
Copy link
Contributor

AVVS commented Nov 12, 2020

@peteraw77 thanks for the PR, but it does definitely need a test case. Error handlers are typically assigned later on in the chain once the connection was created. I dont remember the reasoning for not having an error handler in the create helper, either way a test covering this would be required to get this merged

@peteraw77
Copy link
Author

@AVVS where would be the right place to put the test case?

@peteraw77
Copy link
Author

Added a test in test/functional/connection.ts but I'm having a hard time getting the tests to reproduce the error. This was my best attempt but it's definitely not ideal.

const stub = sinon
.stub(net.Socket.prototype, "connect")
.callsFake((options) => {
net.Socket.prototype.emit("error");
Copy link
Contributor

@AVVS AVVS Nov 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this needs to be async, .connect() doesnt throw in the same tick - wrap this in process.nextTick

https://nodejs.org/api/net.html#net_socket_connect

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, it seems to be capturing the behaviour I intended it to now

@francescov1
Copy link

Is there an expected timeline on when this will be merged? This issue has been causing endless headaches for our team

@drobnikj
Copy link

Ping here. I would be great to merge this fix soon. It generates Unhandled errors, which are hard to debug. In our case it was an error:

[ioredis] Unhandled error event: Error: read EFAULT
    at TCP.onStreamRead (internal/stream_base_commons.js:209:20)
    at TCP.callbackTrampoline (internal/async_hooks.js:126:14)

It takes us time to find that bug comes from this issue.
Thanks!

@francescov1
Copy link

Ping here. I would be great to merge this fix soon. It generates Unhandled errors, which are hard to debug. In our case it was an error:

[ioredis] Unhandled error event: Error: read EFAULT
    at TCP.onStreamRead (internal/stream_base_commons.js:209:20)
    at TCP.callbackTrampoline (internal/async_hooks.js:126:14)

It takes us time to find that bug comes from this issue.
Thanks!

Same here, it's such a simple, obvious but crucial fix...

@kapalkat
Copy link

Please merge that change as we had to write dedicated service to catch those unhandled errors...

@ctrlaltdylan
Copy link

Also pinging! If I was a maintainer I would merge. But alas I am a simple consumer of this great package.

@luin
Copy link
Collaborator

luin commented Mar 10, 2021

Sorry for the late response. I didn't notice this PR... Will take a look soon!

luin added a commit that referenced this pull request Mar 10, 2021
Currently, a stream (ex `net.Socket`) is returned via a Promise, and error
handlers are attached to the stream in the Promise callback.

However, if the errors are thrown immediately (ex with `process.nextTick()`),
the error handlers will not have the chance to attach to the stream, thus
unhandled error events will be thrown.

This PR makes all connectors resolve a factory instead of the created stream,
so the event handlers can be attached in the same tick.

Closes #1236
Closes #1209
Closes #1289
@luin
Copy link
Collaborator

luin commented Mar 10, 2021

reject(err) here actually always does nothing as the Promise has already resolved at line 83. This is equivalent to this.stream.once('error', () => {}), all it does is ignoring the stream error instead of handling them properly. So this PR should be considered as a workaround.

I created a PR to address the root issue: #1296. I'll leave this open and may merge this if I can't get #1296 done very soon. Thank you for the contributions!

@luin luin closed this in #1299 Mar 14, 2021
@ioredis-robot
Copy link
Collaborator

🎉 This issue has been resolved in version 4.24.2 🎉

The release is available on:

Your semantic-release bot 📦🚀

@ctrlaltdylan
Copy link

You the man @luin !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants