flutter web app reporting websockectconnectionclosed

[bsutton]

So the below error.

A couple of notes.

The app is doing continuous polling of the server to display log messages (the tool is a log observation front end).
The app allows you to 'tear off' a log window and open another browser window/tab tailing the selected log.

The error is only happening in the main app window (not the tear off).

I tried restarting the app and creating a new tear off - that wasn't enough to reproduce the problem and at the moment
I don't have an understanding of how to reproduce it.

I'm not seeing any errors in the chrome dev tools network window.
The errors are being reported in the dev tools console and also in the terminal cli that I launch the front end.

The front end still appears to be working without issue. The front end does 6 http request every couple of seconds the below error is output at about the same rate, but doesn't seem to correspond to a particular http request.

The code is currently in a private repo but I do intend to make it public if access to the code would be helpful.

[frontend] Unhandled error detected in the injected client.js script.

You can disable this script in webdev by passing --no-injected-client if it
is preventing your app from loading, but note that this will also prevent
all debugging and hot reload/restart functionality from working.

The original error is below, please file an issue at
https://github.com/dart-lang/webdev/issues/new and attach this output:

WebSocketConnectionClosed: Connection Closed

    at Object.throwExpression (http://localhost:8788/dwds/src/injected/client.js:1312:64)
    at PersistentWebSocket._writeToWebSocket$1 (http://localhost:8788/dwds/src/injected/client.js:24827:13)
    at tear_off.<anonymous> (http://localhost:8788/dwds/src/injected/client.js:1637:45)
    at StaticClosure._rootRunUnary (http://localhost:8788/dwds/src/injected/client.js:4317:18)
    at _CustomZone.runUnary$2$2 (http://localhost:8788/dwds/src/injected/client.js:15140:39)
    at _CustomZone.runUnaryGuarded$1$2 (http://localhost:8788/dwds/src/injected/client.js:15087:14)
    at _ControllerSubscription._sendData$1 (http://localhost:8788/dwds/src/injected/client.js:14587:19)
    at _DelayedData.perform$1 (http://localhost:8788/dwds/src/injected/client.js:14762:59)
    at _PendingEvents_schedule_closure.call$0 (http://localhost:8788/dwds/src/injected/client.js:14821:14)
    at StaticClosure._rootRun (http://localhost:8788/dwds/src/injected/client.js:4298:18)
    at _CustomZone.run$1$1 (http://localhost:8788/dwds/src/injected/client.js:15132:39)
    at _CustomZone.runGuarded$1 (http://localhost:8788/dwds/src/injected/client.js:15075:14)
    at _CustomZone_bindCallbackGuarded_closure.call$0 (http://localhost:8788/dwds/src/injected/client.js:15264:25)
    at StaticClosure._rootRun (http://localhost:8788/dwds/src/injected/client.js:4302:16)
    at _CustomZone.run$1$1 (http://localhost:8788/dwds/src/injected/client.js:15132:39)
    at _CustomZone.runGuarded$1 (http://localhost:8788/dwds/src/injected/client.js:15075:14)
    at _CustomZone_bindCallbackGuarded_closure.call$0 (http://localhost:8788/dwds/src/injected/client.js:15264:25)
    at Object._microtaskLoop (http://localhost:8788/dwds/src/injected/client.js:4148:24)
    at StaticClosure._startMicrotaskLoop (http://localhost:8788/dwds/src/injected/client.js:4154:11)
    at _AsyncRun__initializeScheduleImmediate_internalCallback.call$1 (http://localhost:8788/dwds/src/injected/client.js:13521:9)

[bsutton]

The error seems to start occuring after the front end has been running for some time - less than an hour. Will try to report a lower bound.

No user interaction but the front is updating a log view continuously.

[nshahan]

It sounds like there is potentially a timeout somewhere or the socket is being closed for some other reason, maybe the system has suspended?

Are you running this tool with the extended periods of inactivity time while you are actively developing the app itself? I could be misinterpreting what you're doing but it kind of sounds like you are running the development version of the app as an internal tool. Is this a scenario where you should be building a release version of the app to run instead?

[bsutton]

This is a desktop machine, so the screen lock does kick in, but it doesn't suspend.
I will try to see if it relates to the screen lock.

Yes I'm running this for extended periods without interacting with it. Its fully LLM coded (as a bit of an experiment), so I walk away whilst the llm codes.

I'm only in development mode (its not released as yet) but leave it running for some hours whilst the llm codes and I go and do some welding :)
I've left it running in dev mode intentionally to see how it performs as the data set builds and whether the front end can survive running for long periods - as it will need to do in production.

[nshahan]

Thanks, do share more if you find more information. The error and stack trace you shared are coming from the code we inject into the webpage at development time to communicate between the developer tooling and the running application. It allows us to control the app, reload, restart, etc from your IDE. So it isn't a sign that your application is having a problem.

@jyameo Do you know if we use any timeouts on the web sockets by default or if we have any heartbeat signals to keep it alive during long periods of inactivity?

[bkonyi]

@jyameo Do you know if we use any timeouts on the web sockets by default or if we have any heartbeat signals to keep it alive during long periods of inactivity?

I recently made some changes to DWDS which attempted to fix some issues related to the web socket connection going down after long periods of inactivity or the device going to sleep. The exception appears to be coming from within PersistentWebSocket, which was the class I added to attempt to reestablish the web socket connection if it closed unexpectedly.

If I had to guess, we're ending up in one of the situations where the web socket connection closes unexpectedly and, while we're attempting to reestablish the connection, there's a race condition where we try to add data to the closed web socket.

I think a fix could be to block execution of _writeToWebSocket using a Completer that's null when there's an active connection and is only set when we're trying to reestablish the connection.

[bsutton]

If you want to make a patch, I'm happy to test it for you.

[jyameo]

@nshahan To my knowledge, we don't have any default timeouts set for websockets. As Ben mentioned, the PersistentWebSocket is responsible for re-establishing the connection, and his suggestion for a fix makes sense. I’m currently focused on some other priorities, but I’ll plan to dive into this as soon as I’m able if it hasn't been resolved by then.