Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
eighty4 opened this issue May 8, 2024 · 6 comments
Open

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

eighty4 opened this issue May 8, 2024 · 6 comments
Labels

Comments

@eighty4
Copy link

eighty4 commented May 8, 2024

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
Copy link
Author

eighty4 commented May 8, 2024

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
Copy link
Collaborator

bkonyi commented Nov 13, 2024

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.

@bkonyi bkonyi added P3 A lower priority bug or feature request triaged waiting-for-customer-response labels Nov 13, 2024
@eighty4
Copy link
Author

eighty4 commented Nov 21, 2024

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
Copy link
Author

eighty4 commented Dec 24, 2024

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
Copy link
Author

eighty4 commented Dec 24, 2024

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.

Screenshot 2024-12-23 at 10 52 08 PM

Screenshot 2024-12-23 at 10 52 38 PM

@eighty4
Copy link
Author

eighty4 commented Dec 24, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants