[tool] HttpException: HttpException: Connection closed before full header was received, uri = http://localhost:50094/devtools/page/3036A94908353E86E183B6A40F54104B

[andrewkolos]

Represents 12.01% of CLI tool crashes on 3.24.0 as of 8/11/24. This has existed since 3.22.3 (and probably prior), but it had roughly 20-25% of the number of affected clients throughout the lifetime of that version.

Observed from flutter run, flutter run -d chrome, flutter run -d chrome --machine (e.g. run --machine --start-paused -d chrome --devtools-server-address http://127.0.0.1:9100/ --target /<path to project>/lib/main.dart). Non-exhaustive list.

We don't get stack traces here due to https://github.com/dart-lang/sdk/issues/44994. This is all we get:

HttpException: Connection closed before full header was received, uri = http://localhost:50558/devtools/page/31E436435F75FDDC3F156C20242E9ECD

[andrewkolos]

cc @bkonyi @DanTup in case anyone has ideas on how to even begin to troubleshoot this. This crash appears to have become much more common on 3.24.0 (4x-5x compared to 3.23.3 to-date).

[bkonyi]

cc @kenzieschmoll

[bkonyi]

I'm not sure where to start with this. These failures are always super tricky to figure out with context, but without context it's not clear what exactly is failing.

Based on the DevTools URI, I have a feeling this might be related to serving DevTools extensions since it's not actually referencing a built-in DevTools page?

[kenzieschmoll]

A DevTools extension request would have 'devtools_extensions' in the path, so this doesn't look related to DevTools extensions. Usually requests with devtools in the path occur when DevTools is served from DDS.

[bkonyi]

A DevTools extension request would have 'devtools_extensions' in the path, so this doesn't look related to DevTools extensions. Usually requests with devtools in the path occur when DevTools is served from DDS.

What would result in us making a request to page/3036A94908353E86E183B6A40F54104B then?

[kenzieschmoll]

@andrewkolos do we have any information about whether users were experiencing this error when using an IDE (VS Code, Android Studio, etc.) or when running flutter commands from the CLI? DevTools is served differently in each of these use cases so that would help us narrow down the source of the crash.

[andrewkolos]

@andrewkolos do we have any information about whether users were experiencing this error when using an IDE (VS Code, Android Studio, etc.) or when running flutter commands from the CLI? DevTools is served differently in each of these use cases so that would help us narrow down the source of the crash.

I don't think so, unfortunately. All we really have is the command itself (which I listed a few of in the description). I see some bare flutter runs and some flutter run --machine, so I assume it's happening in both contexts.

[mraleph]

This is most likely a bug in ResidentWebRunner.run. Notice that it does not list HttpException among exceptions it handles and just rethrows it. The exception itself most likely originates in attach which calls ChromeTab.connect which establishes WebSocket connection to the Chrome DevTools protocol: see ChromeTab.connect which calls WipConnection.connect which calls WebSocket.connect. The URL used for the connection is webSocketDebuggerUrl which has the following comment:

  /// Ex. `ws://localhost:1234/devtools/page/4F98236D-4EB0-7C6C-5DD1-AF9B6BE4BC71`.
  String get webSocketDebuggerUrl => _map['webSocketDebuggerUrl'] as String;

Matches[^1] the format we see in the log.

WebSocket.connect will throw this sort of exception if connection terminates abruptly. (maybe there is some sort of race or browser crashes?).

Looking at this code I also noticed that ResidentWebRunner neglects to pass onError callback to ChromeTab.connect. This seems like an oversight (and honestly a questionable API design on the webkit_inspection_protocol.dart package). This callback is used as an onError callback on the WebSocket stream once connection is established. Not passing onError means that all exceptions which occur later (after connection was established and upgraded to WebSocket) are going to be uncaught and will crash Flutter tool as well.

[^1]: That's how I located that package to begin with: did GitHub codesearch for devtools/page, then went backwards into Flutter tool to see how the package is used.

[andrewkolos]

Thanks @mraleph!

This is most likely a bug in ResidentWebRunner.run. Notice that it does not list HttpException among exceptions it handles and just rethrows it

Interesting, judging by the other exceptions handled, I feel like HttpException should be handled here, so I will probably patch this.

WebSocket.connect will throw this sort of exception if connection terminates abruptly. (maybe there is some sort of race or browser crashes?).

I still find this crash becoming much more common 3.24.0 to be concerning. @yjbanov, are you aware of any 3.24.0 regressions in flutter web that may have aggravated whatever underlying issue might exist here?

[andrewkolos]

This appears to still be happening on 3.24.1.

[andrewkolos]

If anyone that is experiencing this crash happens to be reading this, please let us know if you are able to consistently reproduce this.

[andrewkolos]

This appears to still be happening on 3.24.1.

I failed to realize this initially, but the error message being reported now is different: HttpException: Connection closed before full header was received, uri = http://localhost:52097/json. Maybe this should be a different issue.

[andrewkolos]

Filed https://github.com/flutter/flutter/issues/153972.

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.