fix: Prevent connection error in console log for MCDU socket connection attempts

[frankkopp]

Summary of Changes

PR #6937 tried to fix a suspected memory leak but introduced a former issue printing error messages to the console at every connection attempt of the websocket connection to the MCDU Server.

After testing and checking this fix should avoid the error message again and make sure the socket object is properly deleted.

Running this over a longer time did not reveal any memory consumption or fps loss.

Additional context

With debug code:

        console.log('Socket1 = ' + this.socket);

        if (this.socket) {
            if (this.socket.readyState) {
                console.log('Attempting to close socket: readyState=' + this.socket.readyState);
                this.socket.close();
            }
            delete this.socket;
        }

        console.log('Socket2 = ' + this.socket);

        const url = `ws://127.0.0.1:${port}`;

        this.socket = new WebSocket(url);

        console.log('Socket3 = ' + this.socket);

This is the output with MCDU Server off (the number behind DEBUG is the socket.readyState):

[Log] DEBUG: 0================================== (sentry-client.js, line 2182)
[Log] Socket1 = [object WebSocket] (sentry-client.js, line 2182)
[Log] Socket2 = undefined (sentry-client.js, line 2182)
[Log] Socket3 = [object WebSocket] (sentry-client.js, line 2182)

This is the output with MCDU turned on then off:

[Log] DEBUG: 1================================== (sentry-client.js, line 2182, x3)
[Error] WebSocket network error
[Log] WebSocket connection error. Maybe MCDU Server disconnected? (ws://127.0.0.1:8380) (sentry-client.js, line 2182)
[Log] Websocket connection to MCDU Server closed. (ws://127.0.0.1:8380) (sentry-client.js, line 2182)
[Log] DEBUG: 3================================== (sentry-client.js, line 2182)
[Log] Socket1 = [object WebSocket] (sentry-client.js, line 2182)
[Log] Attempting to close socket: readyState=3 (sentry-client.js, line 2182)
[Log] Socket2 = undefined (sentry-client.js, line 2182)
[Log] Socket3 = [object WebSocket] (sentry-client.js, line 2182)
[Log] DEBUG: 0================================== (sentry-client.js, line 2182)
[Log] Socket1 = [object WebSocket] (sentry-client.js, line 2182)
[Log] Socket2 = undefined (sentry-client.js, line 2182)
[Log] Socket3 = [object WebSocket] (sentry-client.js, line 2182)

==> So the socket object is properly deleted. If MSFS still has it in memory and does not garbage collect it is beyond our control.

Discord username (if different from GitHub): Cdr_Maverick#6475

Testing instructions

• Test connection and general function of the Remote MCDU.
• Test C&D - MCDU is already running although not powered and is trying to connect to the Remote MCDU Server.
• Check memory usage and fps over some time to validate that there is no significant memory leak.
• Do this test without power (no other displays) and without EFB.
• If you see any raise in memory usage or fps degradation, make sure to remove everything from Community - really everything. Add-ons like the Toolbar Pushback Helper are known to also have had memory leaks.

How to download the PR for QA

Every new commit to this PR will cause a new A32NX artifact to be created, built, and uploaded.

1. Make sure you are signed in to GitHub
2. Click on the Checks tab on the PR
3. On the left side, click on the bottom PR tab
4. Click on the A32NX download link at the bottom of the page
   …sages

[beheh]

What about readyState == 2 and == 3? Do we want to call socket.close when it's already CLOSING or CLOSED?

(Reference)

[frankkopp]

This is already the case:

if (this.socket) {
    if (this.socket.readyState) { 
        console.log('Attempting to close socket: readyState=' + this.socket.readyState);
        this.socket.close();
    }
    delete this.socket;
}

All non 0 will be closed.
And the call during 3 does not cause an error message as my log above shows.

[frankkopp]

This currently does not solve the issue with websockets not being closed properly.
This seems to be a sim bug that a socket in readyState 0 throws an uncatchable error when .close() is called.
Without calling .close() there seem to remain an object even after delete is called on the object.
This can be observed by growing memory consumption (to exaggerate this remove the update interval throttle) and be opening the Coherent GT Debugger which shows many sockets in Resources.

Investigation for a better solution ongoing - two alternatives:

• adding a setting in the EFB to turn of websockets completely (to avoid the console error message)
• using a different websocket implementation/library

[tracernz]

Option 3, don't use websockets... with keepalive and memorising the failed status (=> only trying at longer intervals) it shouldn't be too much different.

[frankkopp]

Option 3, don't use websockets... with keepalive and memorising the failed status (=> only trying at longer intervals) it shouldn't be too much different.

How to connect to the Remote MCDU Server then?

[frankkopp]

Closing in favor of #6947

[tracernz]

How to connect to the Remote MCDU Server then?

Plain HTTP without websockets.

[Benjozork]

Failed fetch requests also cause lag, so that won't help.

[tracernz]

Big oof. 😬