Repository navigation
improve error messge in lib/dns #3891
Description
Due to backwards compatibility dns.js is reporting UV_EAI_MEMORY, UV_EAI_NODATA, and UV_EAI_NONAME errors as ENOTFOUND
This is currently labelled FIXME --> https://github.com/nodejs/node/blob/master/lib/dns.js#L17-L23
ENOTFOUND is not even a proper POSIX error!
@bnoordhuis
The change breaks a few tests
- test-http-dns-error
- test-net-better-error-messages-port-hostname
- test-net-connect-immediate-finish
- test-net-dns-error
interestingly enough every testc ase we had was for EAI_NONAME, we have no tests for EAI_MEMORY or EAI_NODATA
If people are interested I'll get started on this change, including writing extra tests and smoke testing. This should be a great candidate for citgm
Activity
MylesBorins commentedon Nov 18, 2015
/cc @jasnell @bnoordhuis @cjihrig
cjihrig commentedon Nov 18, 2015
I'm all for removing these types of things from the codebase. My only reservation is that we don't know how much code would break for relatively little gain.
jasnell commentedon Nov 18, 2015
I'm torn. Like @cjihrig I don't see a lot of value but eliminating technical debt is generally a good thing. Smoke testing this would be worthwhile.
silverwind commentedon Nov 22, 2015
We discussed DNS errors in #1843, and ideally we'd like to return real DNS error codes (
NXDOMAIN,SERVFAIL,REFUSEDetc, see section 2.3 of https://tools.ietf.org/html/rfc2929) at some point. It'd be a huge breaking change of course, but if we're going to do it, I'd hold of from changing these now.MylesBorins commentedon Apr 21, 2016
@jasnell is this something I should try and get together for v6? Will it just create too much churn?
jasnell commentedon Apr 21, 2016
We should likely hold off and do this post v6. It's still not yet clear how much this will impact.
silverwind commentedon Apr 21, 2016
These are some exotic errors, I guess it would be pretty low impact, except maybe UV_EAI_NONAME. I'd say we should take the chance and fix this now.
MylesBorins commentedon Apr 21, 2016
@jasnell with that in mind it makes sense to aim to get this in for v7, that way if it was a terrible idea we can back it out in v8 and not be stuck with it for 3 years!
silverwind commentedon Apr 21, 2016
What's the supposed fix going to be, by the way? Remove the conditional and progagate libuv error codes the user?
MylesBorins commentedon Apr 21, 2016
@silverwind indeed. It would be propogated proper error codes
silverwind commentedon Apr 21, 2016
Hmm, I'm just worried about our
E{SOMETHING}convention. ShouldUV_EAI_NONAMEbecomeENONAME?atomantic commentedon Aug 8, 2016
I've been wresting with an ENOTFOUND error (in Node.js
4.4.7) and I'd love to see deeper into why it's failing because it fails after 2,184 successfulhttp.getcalls:This happens within about 30 seconds after service startup.
Any idea how to get more info on what's really happening here?
bnoordhuis commentedon Aug 9, 2016
@atomantic I speculate that if you attach
strace -f(assuming you run linux), system calls start to fail with an EMFILE or ENFILE error code when you get ENOTFOUND.atomantic commentedon Aug 9, 2016
@bnoordhuis thanks. Regardless of why it's happening, I'm going to bypass this by setting up a child process DNS watchdog and simply continue to reference the target by IP. One less thing for the http request to have to do so it should be better performance anyway and removes the potential for a cache lookup or DNS resolution mishap.
jasnell commentedon Mar 24, 2017
ping @MylesBorins ... what do you want to do with this one?
Trott commentedon Jul 30, 2017
I don't think this is going to happen any time soon, although a clean CITGM run would go a long way towards making it seem more possible. I'm going to close this for now, but definitely re-open it if you're working on it.