After thinking this through, I feel like the listenerForInvokeHandler (where the payload.id access could error) should handle the possible error in the first place. Alternatively, we update the WebSocketCustomListener types to allow returning void | Promise<void> so it's clear that we will handle it accordingly. Reasoning being that there's many APIs out there that return void and it'd be difficult to assume every function could possibly return a rejected promise.

I feel like the listenerForInvokeHandler (where the payload.id access could error) should handle the possible error in the first place.

Where do you think the error should be returned? Should we have error event on the HotChannel?

Alternatively, we update the WebSocketCustomListener types to allow returning void | Promise<void> so it's clear that we will handle it accordingly.

IIRC void | Promise<void> is the same as void because void means it doesn't care about the return value. If we were to change to that, we need to change it to undefined | Promise<void>