-
Notifications
You must be signed in to change notification settings - Fork 103
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
Fix issues with node 0.12 #73
Conversation
This fixes 2 failing test cases, and adds a new related non-failing case
!!! Thanks so much @kanongil |
|
||
var _abort = req.abort; | ||
var aborted = false; | ||
req.abort = function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not a fan of changing the node req
object. Can you find another way to solve this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately not, as far as I can tell. This can only be resolved in node itself. You are welcome to submit a bug report.
As it stands, if abort()
is called before the socket has been assigned, node >= 0.12 will silently drop the request without any further emits on the request object. This is all handled in https://github.com/joyent/node/blob/master/lib/_http_client.js.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who else can call abort()
other than line 87? Because is no one, then why override the node internals?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
abort()
is part of the exposed api in the req object that is returned. It should definitely be supported. Without this patch an early abort()
call can cause the request callback to never be called.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But what is the use case? It's one thing to protect the wreck internals but I don't think wreck users should be calling abort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is more of a question for node. It is part of the public api, and I guess they have a reason for it to be there. See http://nodejs.org/api/http.html#http_request_abort. It is inherently also part of the wreck api, with test cases to support it. Also, there is no way to remove this.
My primary concern is that without this (or similar) patch, users can experience obscure timing related bugs when using abort. It is quite bad form to have a callback that is not always called.
I definitely agree that it sucks to do this, and I ultimately think that this should be solved in node. Until then I think we have 3 options:
- Use this patch
- Drop the abort tests & document divergent abort behavior
- Drop 0.12 support
Finally, there is a small possibility that I'm wrong about the missing notification and it can be solved without a hack. You are welcome to look for it.
a405c10
to
865900c
Compare
@chrisdickinson @cjihrig Can you chime in? |
Based on a little poking around, this seems to be a bug to me (although Chris may disagree). There is |
@cjihrig An Given that this is a node 0.12+ problem, we could actually detect the abort using |
And what a convenience that would be right now :-) I don't think explicitly aborting a request should result in an error, but that is beside the point. I wrote the |
@cjihrig +1 on an "abort" event, though that would still leave us with a few patch versions of Node that wreck would not support due to this bug. Is that acceptable? |
@geek is the lead maintainer, so it's his call. Could always use a hackier approach until official support lands. FWIW, nodejs/node-v0.x-archive#9278 and nodejs/node#945 |
Is this a bug in node 0.12? If it is, can we just fix it there and then note the version requirements? |
This has landed in io.js. TJ is OK with the change to Node, but said that it can't go into 0.12. His recommendation was to monkey patch |
@cjihrig what was the reason for not allowing it in 0.12? |
It's technically an API change. |
Seems like we got our answer. What's the proposed solution to make this work across 0.10, 0.12, and io? |
As far as I can tell we are down to monkey patching, as I did and TJ suggests, and using |
Given that TJ's suggestion was to monkey patch |
I'll let @geek decide how to proceed. |
@kanongil this will be published with v5.3.0. Thanks for fixing this. |
This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions. |
The main issue is that calls to
abort()
can now cause the stream to stop without any notification at all. As a consequence, I have implemented a workaround that intercepts all calls toabort()
.The SSL test fix might be specific to my homebrew 0.12 install, though it should not cause any issues.