dns error needs more information in it

[bpytlik]

I recently tracked down a bug in my software to a misconfigured syslog host. The problem is that the error:

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: getaddrinfo ENOTFOUND
    at errnoException (dns.js:37:11)
    at Object.onanswer [as oncomplete] (dns.js:124:16)

Gave me no idea where the error was coming from. In a large application with many potential entry points to dns, this is problematic. I had to resort to monkey patching dns.js (and eventually dgram.js) before I was able to determine where the error was coming from. In a production setting, there would be no hope of diagnosing the problem and catching the error.

I don't know whether this should be addressed in dns.js or in dgram.js (Socket.prototype.send), but the consequences in my case were severe (the program exited).

The information I found useful was the content of the domain variable. That gave me a clue, but the family and callback could also be useful. Ideally, a real stack would be available but I know that's harder to accomplish.

[tjfontaine]

In general, the issue was more likely that you were missing an .on('error') handler on the socket/server, if you'd like to verify that you can post a reproducible test case.

var dgram = require('dgram');
var udp = dgram.createSocket('udp4');

var hw = new Buffer('Hello World');

udp.send(hw, 0, hw.length, 12346, 'I do not exist');

// following here is what you were missing
udp.on('error', function(err) {
  console.log(err);
});

That being said, there is already an open issue #7005 with the desire to add more context to error objects for additional useful state. So if possible your request could be rolled into that one.

Alternately there stack trace modules and agents that are designed to recombine async operations into more useful stack traces, you could try one of those.

Thanks.

[bpytlik]

I was indeed lacking a .on("error"). This bug wasn't that the error was happening. It was that the error contained no useful information for me to discover why it was happening or what code was triggering the error. The problem is that finding the (hopefully) one location where I'm missing that error handler in ~20k lines of code isn't trivial. Issue #7005 does cover my issues I think, assuming a broad interpretation of that issue is taken so that it fixes more than the issue in net.js line 892.

As a side note, I did try longjohn which purports to provide the missing stack trace. That simply didn't work. If you have other recommendations for modules which help track async operations, I'd be happy to hear about them.

[papandreou]

At one point I monkey-patched the net module so that the Socket constructor captured a stack trace by creating a new Error object and saved it on the Socket instance. That way I could tell where the socket was originally created when it threw an error later, allowing me to easily find the bug.

I didn't try to measure the overhead, so I don't know whether the approach would be suitable in production.