[BUG] Unresolved host for udp.send() causes unhandled exception.

[phillipivan]

Is this a bug in companion itself or a module?

• I believe this to be a bug in companion

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

From slack discussion link

A udp.send() to an unresolved host via the UDPHelper will return an uncaught exception:

error: node:internal/errors:496 ErrorCaptureStackTrace(err); ^ Error: getaddrinfo ENOTFOUND 192.168.46.047 at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:107:26) { errno: -3008, code: 'ENOTFOUND', syscall: 'getaddrinfo', hostname: '192.168.46.047' } Node.js v18.20.2

Seemingly no current modules that use UDP catch these, and consequently it is a crash risk for all. For modules that initiate traffic on init/config updated, this can result in a crash loop where the module config can no longer be accessed or updated from inside companion, and either needs to be deleted or edited by external means.

This was discovered running under windows where Regex.IP will accept IPs with a leading zero, but windows cant handle them (as decimal or octal), and reproduced with an unresolvable host name. The former case does not return an error under Linux.

Behavior has not been tested yet when performing a send() from SharedUdpSocket.

Possible solutions include:

• Catching in UDPHelper and emitting an error event.
• Silently catching in UDPHelper.
• Getting modules to individually catch.

Obviously this could also be individually listed as an issue against each module currently using UDPHelper, but given the number of potentially impacted modules, and the possibility that a fix in companion/companion-module-base is preferable listing here for the time being.

Steps To Reproduce

1. Create module that uses UDP.
2. Enter IP with leading 0 in a byte.' (under windows), or an unresolved host name if the module accepts host names.
3. Save Config.
4. Make sure a message is sent if it is not done automatically during config updated.

Expected Behavior

Modules don't crash. Error logged. Ideally module status updated (obviously this part would require module changes).

Environment (please complete the following information)

- OS: Windows 10
- Browser: Chrome
- Companion Version: 3.4 7156

Additional context

No response

[istnv]

I just tested with generic-tcp-udp on Linux using a bogus machine (unresolvable) dns name.
There is a handler for .on('error', but the module crashes and restarts without notifying the module.
At this point, your third option (letting the module handle the error) is not possible.

[phillipivan]

@istnv I am able to catch the error with the following:

await this.socket
		.send(JSON.stringify(msg))
		.then(() => {
			if (this.config.verbose) {
				this.log('debug', `Sent message: ${JSON.stringify(msg)}`)
			}
		})
		.catch((error) => {
			this.log('error', `Message send failed!\nMessage: ${JSON.stringify(msg)}\nError: ${JSON.stringify(error)}`)
			this.updateStatus(InstanceStatus.ConnectionFailure, error.code)
		})

But obviously that requires the respective modules to be updated to catch it on the send() (and then provide some pretty clear guidance to future devs).

[istnv]

The TCPHelper library catches and forwards the error to the module and doesn't require the promise gymnastics.
UDPHelper should behave the same. It is an edge case, but it should be handled.

[jwetzell]

I don't believe the TCPHelper is catching the errors inside the returned promise either. I did test adding the outer try-catch block to UDPHelper like in TCPHelper and this error is not caught there.