Delay in Instance Status Updates at Driver-Level

[joepavitt]

Current Behavior

In reviewing #1926 I have significant delays (> 5 minutes) of retrieving status updates. This seems to be happening at the localfs driver level, rather than linked to polling - @Pezmc and I were logging inside the liveState() function found in /forge/db/models/Project.js and this will[ regualrly reporting "starting" as the status, despite the Node-RED logs reporting "started flows" around 5 minutes ago.

Expected Behavior

The status should be reflected to it's Live condition.

Steps To Reproduce

Restart an instance of Node-RED within FlowForge, when running the localfs driver

Environment

• FlowForge version: branch linked with: Application Instances: Live statuses #1926
• Node.js version: v18.15.0
• npm version:
• Platform/OS: Mac
• Browser: Chrome

[joepavitt]

Need to check if in staging when we deploy

[joepavitt]

verified this isn't an issue on Staging, but is still a problem locally. Downgrading the priority label

[joepavitt]

Debugging with Nick, tracked down to statusPoll inside nr-launcher/llib/launcher.js - imminent changes due with an open PR, want to wait for those changes to merge, before investigating further, as we are at the point of debugging out-dated code.

[joepavitt]

Tracked to status polling trying to reach an ipv6 address, rather than localhost:

RequestError: connect ECONNREFUSED ::1:12080

this.settings.baseURL is set correctly (http://localhost;12080), Nick isn't sure what's going on.

[hardillb]

We need to check settings.js to see what it's binding to. We've run into this on normal Node-RED recently (I'll try and find the issue I discussed it with DCJ in )

[hardillb]

This was a WebSockets issue, but it feels the same:

node-red/node-red#4010

It's down to how newer versions of NodeJS order DNS results and I think NR defaults to binding to 0.0.0.0 which is IPv4 only where as binding to :: would bind to both if available.

And the OS returns both ::1 and 127.0.0.1 for localhost these days.

[joepavitt]

Forgot to mention I'm running node v18, Nick was on an older version, and also concluded this was a Node version issue.

[hardillb]

I can think of 2 fixes for this

1. We change the flowforge-nr-launcher to set uiHost to :: to override the default of 0.0.0.0 which will get Node-RED to bind to both IPv4 and IPv6. I'm not 100% sure what happens on a machine with no IPv6 at all in this case. (Pretty much all OS these days enable IPv6 by default, even if there is no address setup loopback will still get assigned ::1)
2. We change the flowforge-driver-localfs to use 127.0.0.1 rather than localhost as the hostname for all it's interaction with Node-RED, this would work round the change in order that IP name mappings are returned by the newer versions of NodeJS

[joepavitt]

I have verified (with Ben) that 1. does fix the issue for me locally.