NR is crashing after update to NR4.0.0 and contrib unifi 0S 1.0.0

[canedje]

Nr is crashing emidiatly after start caused bij the unifi OS pallet. I restarted several times giveing the same error crashing the NR docker. I removed the unifi OS pallet and now NR keeps running NR docker version: 4.0.0 node-red-contrib-unifi-os version: 1.0.0 Error LOG:

21 Jun 15:07:00 - [red] Uncaught Exception:
21 Jun 15:07:00 - [error] TypeError: Cannot read properties of undefined (reading 'includes')
    at init.<anonymous> (/data/node_modules/node-red-contrib-unifi-os/build/nodes/Protect.js:214:35)
    at Generator.next (<anonymous>)
    at /data/node_modules/node-red-contrib-unifi-os/build/nodes/Protect.js:31:71
    at new Promise (<anonymous>)
    at __awaiter (/data/node_modules/node-red-contrib-unifi-os/build/nodes/Protect.js:27:12)
    at Object.handleUpdate [as dataCallback] (/data/node_modules/node-red-contrib-unifi-os/build/nodes/Protect.js:139:40)
    at /data/node_modules/node-red-contrib-unifi-os/build/SharedProtectWebSocket.js:126:42
    at Array.forEach (<anonymous>)
    at WebSocket.<anonymous> (/data/node_modules/node-red-contrib-unifi-os/build/SharedProtectWebSocket.js:124:57)
    at WebSocket.emit (node:events:519:28)
    at Receiver.receiverOnMessage (/data/node_modules/ws/lib/websocket.js:1209:20)
    at Receiver.emit (node:events:519:28)
    at Receiver.dataMessage (/data/node_modules/ws/lib/receiver.js:567:14)
    at Receiver.getData (/data/node_modules/ws/lib/receiver.js:496:10)
    at Receiver.startLoop (/data/node_modules/ws/lib/receiver.js:167:16)
    at Receiver._write (/data/node_modules/ws/lib/receiver.js:94:10)
    at writeOrBuffer (node:internal/streams/writable:564:12)
    at _write (node:internal/streams/writable:493:10)
    at Writable.write (node:internal/streams/writable:502:10)
    at TLSSocket.socketOnData (/data/node_modules/ws/lib/websocket.js:1303:35)
    at TLSSocket.emit (node:events:519:28)
    at addChunk (node:internal/streams/readable:559:12)

[Shaquu]

Looking into it

[Shaquu]

node-red/node-red/issues/4780

[marcus-j-davies]

v1.0.1 released.

This address a missing config parameter that was introduced in v1 opening the Protect Node/saving/deploy will fix it.

but v1.0.1 stops it for future users updating to the v1 release

[canedje]

Still crashing. Not as much as before. Now once a day:

23 Jun 21:00:26 - [error] [change:5bb589225a0ed484] Invalid JSONata expression: Unable to cast value to a number: "-3;;f;l"
23 Jun 21:21:08 - [error] [api-call-service:Notify all] InputError: Invalid JSON: {"title":"LICHT:","message":"Licht woonkamer aangezet door lichtsensor. 
 waarde = 12","data":{"ttl":0,"priority":"high"}}
23 Jun 21:25:26 - [error] [change:5bb589225a0ed484] Invalid JSONata expression: Argument 1 of function "number" does not match function signature
23 Jun 22:55:26 - [error] [change:5bb589225a0ed484] Invalid JSONata expression: Argument 1 of function "number" does not match function signature
23 Jun 23:53:23 - [red] Uncaught Exception:
23 Jun 23:53:23 - [error] Error: WebSocket is not open: readyState 0 (CONNECTING)
    at WebSocket.ping (/data/node_modules/ws/lib/websocket.js:361:13)
    at SharedProtectWebSocket.<anonymous> (/data/node_modules/node-red-contrib-unifi-os/build/SharedProtectWebSocket.js:74:72)
    at Generator.next (<anonymous>)
    at fulfilled (/data/node_modules/node-red-contrib-unifi-os/build/SharedProtectWebSocket.js:5:58)
    at runNextTicks (node:internal/process/task_queues:60:5)
    at listOnTimeout (node:internal/timers:540:9)
    at process.processTimers (node:internal/timers:514:7)
24 Jun 05:56:52 - [info] 

[marcus-j-davies]

Strange.

watchDog that ping occurs re-starts its self after a pong & watchDog only occurs after a connection some race condition I have missed I guess.

  private HEARTBEAT_INTERVAL = 10000
  private RECONNECT_TIMEOUT = 15000

  private async watchDog(): Promise<void> {
        setTimeout(async () => {
            await this.updateStatusForNodes(SocketStatus.HEARTBEAT)
            this.ws?.ping()

            const reconnectTimer = setTimeout(async () => {
                await this.updateStatusForNodes(
                    SocketStatus.RECOVERING_CONNECTION
                )
                this.disconnect()
                this.connect()
            }, this.RECONNECT_TIMEOUT)

            this.ws?.once('pong', async () => {
                clearTimeout(reconnectTimer)
                await this.updateStatusForNodes(SocketStatus.CONNECTED)
                this.watchDog()
            })
        }, this.HEARTBEAT_INTERVAL)
    }

RECONNECT_TIMEOUT might have occurred before the pong was received, and ping/pong should be near instant (or at least 1-2s whilst there is an active connection

i.e pong took >15s (that should not be the case), and results in a new watchDog whilst the other was a ticking time bomb that fired at RECONNECT_TIMEOUT

Will try and review it as soon as I can

[marcus-j-davies]

OK,

I'm going to unsubscribe to a pong during a re-connect. To me, it seems for some reason, the pong was received a lot later than should have been.

so the re-connect started (Connecting) and during this - the late pong was received (queuing another ping) whilst still connecting, because the original pong took it's time to reach us (when it should be only 2-5 seconds)

its all I have for now - its a bit weird

How the watchDog works

[canedje]

Thanks for the effort