[BUG] Server Application Crash - TypeError: Cannot use 'in' operator to search for 'message' in header is wrong

[AndyFug]

Is this a bug in companion itself or a module?

• [X] I believe this to be a bug in companion

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

Hi.

We are getting a brief (3 secs or so) crash of Companion when we run the companion-module-iiyama-prolite module to control a Iiyama Prolite screen using the LHxx42UHS protocol.

The crash appears to happen when we trigger any of the module's actions, but for the purposes of this report, specifically when we run a prolite: Change Input action, setting the TV input to HDMI 1.

I have tried to run this on Companion versions v3.2.0, v3.2.2 and 3.99.0+6806-develop-9ccb6d95, and all versions behave exactly the same.

I have submitted an issue on the module's repo: companion-module-iiyama-prolite/issues/6

Steps To Reproduce

1. Add connection for companion-module-iiyama-prolite module to a single TV.
2. Setup an action on a button: prolite: Change Input with input option HDMI 1
3. Press the button/trigger the action.
4. Server crashes ('Houston we have a problem message' and surfaces disconnect) when the button is pressed.
5. Server recovers after about 3 secs.

Expected Behavior

No Companion server crash.

Environment (please complete the following information)

- OS: Mac OS 13.6 (22G120)
- Browser: Chrome - Version 123.0.6312.105 (Official Build) (arm64)
- Companion Version: 3.2.0 / 3.2.2 / 3.99.0+6806-develop-9ccb6d95

I have tried this on two devices: Macbook Pro (M2 Pro) and a Mac Studio (M2 Max).

Additional context

Here are some log entries at the time of the crash from ~/Library/Application Support/companion/logs/companion-2024-04-04.0.log:

TypeError: Cannot use 'in' operator to search for 'message' in header is wrong
    at t.IpcWrapper.receivedMessage (/Applications/Companion.app/Contents/Resources/main.js:2:2451698)
    at ChildProcess.a (/Applications/Companion.app/Contents/Resources/main.js:2:2792667)
    at ChildProcess.emit (node:events:529:35)
    at ChildProcess.emit (node:domain:489:12)
    at emit (node:internal/child_process:944:14)
    at process.processTicksAndRejections (node:internal/process/task_queues:83:21)
sentry error {
    "values": [
        {
            "type": "TypeError",
            "value": "Cannot use 'in' operator to search for 'message' in header is wrong",
            "stacktrace": {
                "frames": [
                    {
                        "filename": "node:internal/process/task_queues",
                        "module": "task_queues",
                        "function": "process.processTicksAndRejections",
                        "lineno": 83,
                        "colno": 21,
                        "in_app": false
                    },
                    {
                        "filename": "node:internal/child_process",
                        "module": "child_process",
                        "function": "emit",
                        "lineno": 944,
                        "colno": 14,
                        "in_app": false
                    },
                    {
                        "filename": "node:domain",
                        "module": "node:domain",
                        "function": "ChildProcess.emit",
                        "lineno": 489,
                        "colno": 12,
                        "in_app": false
                    },
                    {
                        "filename": "node:events",
                        "module": "node:events",
                        "function": "ChildProcess.emit",
                        "lineno": 529,
                        "colno": 35,
                        "in_app": false
                    },
                    {
                        "filename": "app:///main.js",
                        "module": "main",
                        "function": "ChildProcess.a",
                        "lineno": 2,
                        "colno": 2792667,
                        "in_app": true,
                        "pre_context": [
                            "/*! For license information please see main.js.LICENSE.txt */"
                        ],
                        "context_line": "'{snip} message: ${JSON.stringify(e)}`)}),5e3);const a=e=>{this.#H.receivedMessage(e)};r.child.on(\"message\",a),this.#kr=()=>{r.child.off(\"message\",a {snip}",
                        "post_context": []
                    },
                    {
                        "filename": "app:///main.js",
                        "module": "main",
                        "function": "t.IpcWrapper.receivedMessage",
                        "lineno": 2,
                        "colno": 2451698,
                        "in_app": true,
                        "pre_context": [
                            "/*! For license information please see main.js.LICENSE.txt */"
                        ],
                        "context_line": "'{snip} :void 0;if(e.success)t.resolve(r);else{let e=r;r&&\"message\"in r&&(e=new Error(r.message),r.stack&&(e.stack=r.stack)),t.reject(e)}break}defau {snip}",
                        "post_context": []
                    }
                ]
            },
            "mechanism": {
                "type": "onuncaughtexception",
                "handled": false
            }
        }
    ]
}
2024-04-04T14:38:04.202Z Application: Companion exited with code: 1
2024-04-04T14:38:04.203Z Application: Restart Count: 1
2024-04-04T14:38:05.504Z info Log/Controller Application starting
2024-04-04T14:38:05.505Z info Registry Build 3.2.2+6688-stable-7417d2a0

[Julusian]

This is happening because the module is throwing a string rather than an error. https://github.com/bitfocus/companion-module-iiyama-prolite/blob/ecdfb68eb4a27413aaf3d01d63476d022b3bc348/src/prolite-api/protocols/LH42UHS.ts#L182 And I didn't think to test that...

[AndyFug]

Thank you. I meant to respond here to remark on my findings. After some debugging, I was concluding myself that it was something to do with that error handling.

I managed to stop the crash by commenting out this line, which I believe is causing the checkReply method to be called twice.

checkReply is already called in the readReply method, which slices out some of the message, making it invalid on the second call of checkReply.

I'll flag this on the module's repo.

[Julusian]

I have fixed this on the companion side, it will be in the next beta