Vite proxied `flutter run -d chrome` does not respond with RunRequest

[eighty4]

I'm proxying flutter run -d chrome --web-port 5710 through a Vite proxy and it doesn't respond with a RunRequest over the dwds websocket. When flutter.js, proxied through vite to run embedded in a Svelte app, creates the connection to the WebSocket, RunRequest never gets returned from the WebScoket.

Here is the code I can manually run in the console to get a RunRequest (I copied this by going to http:localhost:5710 and copying ConnectRequest from the Network tab):

const ws = new WebSocket('ws://localhost:5173/$dwdsSseHandler')
ws.send('["ConnectRequest","appId","Im4Su93feIfeEOgiTPFjmA==","instanceId","006dcb10-0d68-11ef-907d-716f5f111410","entrypointPath","main_module.bootstrap.js"]')

RunRequest is returned in response to the ConnectRequest through the WS proxy, so I've verified it's not the WebSocket proxy or a hostname origin issue. Do you have any ideas why this wouldn't respond with this event?

Here is the vite config:

import {sveltekit} from '@sveltejs/kit/vite'
import {defineConfig} from 'vite'

export default defineConfig({
    server: {
        proxy: {
            '/dev/ui': {
                rewrite: (path) => path.replace(/^\/dev\/ui\//, '/'),
                target: 'http://localhost:5710',
                ws: true,
            },
            '/$dwdsSseHandler': {
                target: 'http://localhost:5710',
                ws: true,
            },
        },
    },
    plugins: [sveltekit()],
})

[eighty4]

Trying to debug/read code (to no avail) and was curious to see that neither appId nor instanceId match when proxying through Vite vs connecting to flutter run's dwds ws directly. Why would that be the case?

["ConnectRequest","appId","Im4Su93feIfeEOgiTPFjmA==","instanceId","13994f00-0d6f-11ef-ba4b-ff8af6980f25","entrypointPath","main_module.bootstrap.js"]

["ConnectRequest","appId","f9Hzqrgk3bDXbjTJIfpzDg==","instanceId","0f3c5d80-0d6f-11ef-8b2d-13db2147535e","entrypointPath","main_module.bootstrap.js"]

[bkonyi]

Hi @eighty4,

Were you able to figure this out? It looks like you're assuming that /$dwdsSseHandler is a websocket endpoint but that's actually the SSE (server sent event) handler.

[eighty4]

I never resolved the issue nor could workaround it. I also haven't tried recreating it since reporting a few Flutter versions ago.

Maybe removing ws: true will fix it. I'll give that a try, but seems weird that Vite's proxy would make a WS request on an HTTP GET.

Hopefully during the holidays I'll have time to revisit the hobby project this occurred in.

[eighty4]

Even though that Vite proxy says Sse in the pathname, it is a WS connection.

I still have no idea what prevents a debug web server from bootstrapping when reverse proxied. It would be ideal to run a webapp and a flutter run -d web-server --web-port 5678 and have hot reload work with the Flutter app embedded in a webapp.

The proxying works fine if i run with --release as its only proxying js and wasm and what not so works as expected. Just not sure why the debug WS ignores the connection if it's through a proxy.

[eighty4]

The first image is flutter run -d chrome --web-port 5710 and proxied through Vite. It connects to the WS, sends the message, yet the dart web server doesn't respond. HMR can be triggered from the terminal but it doesn't affect the browser session.

The second image is of the messages exchanged after the initial connect message if connecting without the reverse proxy in the middle and operating as expected.

[eighty4]

Alright, did some testing between the different modes after looking at the code.

flutter run -d chrome --release proxies through a reverse proxy because there's no dwds to block on RunRequest not firing

flutter run -d chrome --debug starts up in debug mode just fine in the launched browser but proxying through the reverse proxy the logs stop after and ConnectRequest never elevates to RunRequest:

Loading from existing service worker.
flutter_bootstrap.js:3 Service worker already active.
flutter_bootstrap.js:1 Injecting <script> tag. Using callback.

inject.dart does add the vars to window when proxied through a local web server, unlike flutter run -d web-server, which prints this out to the DevTools console:

hook.js:608 registerExtension() from dart:developer is only supported in build/run/test environments where the developer event method hooks have been set by package:dwds v11.1.0 or higher.```

Without dwds not starting up it `-d web-server` behaves identically to `-d chrome --release`, no logs, hot reload, etc.

Still not sure why Dart Debug extension doesn't work with `-d web-server` or `-d chrome` connects to Dwds through a reverse proxy but doesn't elevate to RunRequest.