dgram: don't swallow bind errors when callback is provided

[armanmikoyan]

dgram: don't swallow bind errors when callback is provided

When Socket.prototype.bind() is called with a callback, the internal
cleanup listener is registered on 'error', which counts as an error
handler and silently swallows bind errors (e.g. EADDRINUSE) when no
user error handler is attached.

This switches to EventEmitter.errorMonitor for the cleanup listener,
matching the pattern already used in the enqueue() function
(lib/dgram.js:571). This ensures bind errors properly propagate as
unhandled errors while still performing listener cleanup.

Setup — a socket already bound to port 5000

import dgram from 'dgram';

const receiver = dgram.createSocket('udp4');

receiver.bind({ port: 5000, address: '127.0.0.1' });

No callback, no listening event — error surfaces (correct)

import dgram from 'dgram';

const socket = dgram.createSocket('udp4');

socket.bind({ port: 5000, address: '127.0.0.1' }); 
// Throws: Error: bind EADDRINUSE 127.0.0.1:5000

Using listening event — error surfaces (correct)

import dgram from 'dgram';

const socket = dgram.createSocket('udp4');

socket.on('listening', () => {
  console.log('bound');
});

socket.bind({ port: 5000, address: '127.0.0.1' });
// Throws: Error: bind EADDRINUSE 127.0.0.1:5000

Using callback — error silently swallowed (bug)

import dgram from 'dgram';

const socket = dgram.createSocket('udp4');

socket.bind(
  { port: 5000, address: '127.0.0.1' },
  () => { console.log('bound'); },
);
// No error, no output — process hangs

All three examples do the same thing — bind to a port already in use.
The first two properly throw, but the third silently swallows the error
just because a callback was passed to bind().

After this fix, all three cases properly surface the error.

[nodejs-github-bot]

Review requested:

• @nodejs/net

[Ethan-Arrowood]

This seems appropriate to me. Even if a fix, this is a notable change in behavior. I believe notable-change is warranted at least. I'm not sure about semver. I don't want to tag all of the TSC, but I'll see if http/net folks have any input as the dgram subsystem is relatively close to those.

[Ethan-Arrowood]

cc @nodejs/net @nodejs/http

[mcollina]

lgtm

[mcollina]

No, I think this is just a bug fix

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/74830/

[armanmikoyan]

@mcollina I can't access the CI logs. Could someone let me know if the failures are related to my changes or just flaky? Happy to fix them if needed, or a re-run would be appreciated if they're unrelated.

[Ethan-Arrowood]

CI failure looks unrelated to me; its a sqlite-backup flake and some rebase infra issue.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/76251/

[nodejs-github-bot]

Landed in 97c7e32