On another topic: with this test program I also saw 2 crashes. Before your change and after, so I suspect this is something totally different. I can’t reproduce it (yet), but maybe this hint does help you:
MOO: reached end of buffer while parsing header
<- undefined undefined undefined
let cb = this.requests[msg.request_id].cb;
TypeError: Cannot read property 'cb' of undefined
at Moo.handle_response (/home/harry/dev/ROPIEEE/roon-ext-test/node_modules/node-roon-api/moo.js:187:44)
at Transport.transport.onmessage.msg [as onmessage] (/home/harry/dev/ROPIEEE/roon-ext-test/node_modules/node-roon-api/lib.js:419:27)
at WebSocket.Transport.ws.onmessage (/home/harry/dev/ROPIEEE/roon-ext-test/node_modules/node-roon-api/transport-websocket.js:30:14)
at WebSocket.onMessage (/home/harry/dev/ROPIEEE/roon-ext-test/node_modules/ws/lib/WebSocket.js:442:14)
I guess that is another (more extreme) way to suspend execution
I have not looked under the hood, but I am guessing that somewhere that is a hash of messages sent that are expecting a response each with a timeout. On a timeout a messages awaiting a response is removed, then eventually a delayed response message arrives and by that time the message in no longer ion the hash and end result is exception when dereferencing the callback handler.
Assuming something like the above, then in node it is very easy provoke such a problem because of the single threaded co-operative nature of it. It just takes one bit of code somewhere to take too long on some synchronous operation.