Avoid unnecessary reload after HMR WebSocket connection lost

[vilicvane]

Clear and concise description of the problem

Currently Vite reloads the page after a successful ping after connection lost.

In a hybrid app, once the app launches another app, the connection lost. When the app switches back, the app reloads. To properly debug routines involve switching to another app, we have to either use production build or comment out location.reload() in vite/dist/client/client.mjs.

Suggested solution

Reconnect WebSocket to check HMR status instead of reload unconditionally.

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[zhengjiaqi]

I have same problem #6089

[hkhanna]

I want to flag an important reason I'd like to be able to deactivate the websocket.

An active websocket blocks the bfcache on the browser. So the bfcaching caching behavior locally is different than the caching behavior in prod, where there is no websocket, at least for me. I therefore couldn't reproduce a certain cache-related bug locally until I realized the Vite websocket was affecting it. Because there was no way to shut off websockets completely, I had to strip Vite out to be able to reproduce the bug.

Just leaving this comment here since I didn't see any reference to this caching issue in any of the websocket-related Vite issues, and I'm sure someone will have this problem someday.

[sapphi-red]

@niksy

How this happens is:

When the web socket connection was disconnected, Vite's HMR client starts to ping to http://yourserver/websocket-path.

vite/packages/vite/src/client/client.ts

Lines 311 to 333 in 29abeea

	async function waitForSuccessfulPing(
	socketProtocol: string,
	hostAndPath: string,
	ms = 1000,
	) {
	const pingHostProtocol = socketProtocol === 'wss' ? 'https' : 'http'
	// eslint-disable-next-line no-constant-condition
	while (true) {
	try {
	// A fetch on a websocket URL will return a successful promise with status 400,
	// but will reject a networking error.
	// When running on middleware mode, it returns status 426, and an cors error happens if mode is not no-cors
	await fetch(`${pingHostProtocol}://${hostAndPath}`, {
	mode: 'no-cors',
	})
	break
	} catch (e) {
	// wait ms before attempting to ping again
	await new Promise((resolve) => setTimeout(resolve, ms))
	}
	}
	}

When the Vite server starts, Vite will respond to that ping request.
Then, Vite's HMR client reload the page.

vite/packages/vite/src/client/client.ts

Lines 103 to 105 in 29abeea

	console.log(`[vite] server connection lost. polling for restart...`)
	await waitForSuccessfulPing(protocol, hostAndPath)
	location.reload()

But this has some edge cases. For example, when WebSocket server starts after the HTTP Server (can happen in middleware mode).

Where we need to change is:

• Change the ping to use WebSocket instead of HTTP:

  vite/packages/vite/src/client/client.ts

  Line 311 in 29abeea

  async function waitForSuccessfulPing(

• Handle that WebSocket connection:

  vite/packages/vite/src/node/server/ws.ts

  Line 80 in 29abeea

  export function createWebSocketServer(

I guess we need to use a different protocol(sec-websocket-protocol) to differentiate the normal connection and the ping connection.

[niksy]

@sapphi-red

Change the ping to use WebSocket instead of HTTP:

Does this mean we need to create our own WebSocket server and reference it in Vite server.hmr.server property?

[sapphi-red]

Does this mean we need to create our own WebSocket server and reference it in Vite server.hmr.server property?

No, Vite already has a WebSocket server and we can reuse that.

[psychedelicious]

Would love to see this be configurable.

For my situation (a very simple vite server setup w/ some proxies for socketio and our api, nothing else), this diff allowed me to retain HMR functionality but not reload the page:

diff --git a/dist/client/client.mjs b/dist/client/client.mjs
index e944ed731f936d5a35fe8368ce55c0518ade537e..ba56411cce8960a5dd0c47bf9b3bb13a8b8498f6 100644
--- a/dist/client/client.mjs
+++ b/dist/client/client.mjs
@@ -483,7 +483,7 @@ function setupWebSocket(protocol, hostAndPath, onCloseWithoutOpen) {
         notifyListeners('vite:ws:disconnect', { webSocket: socket });
         console.log(`[vite] server connection lost. polling for restart...`);
         await waitForSuccessfulPing(protocol, hostAndPath);
-        location.reload();
+        setupWebSocket(protocol, hostAndPath, onCloseWithoutOpen)
     });
     return socket;
 }

It's not clear if this would break other things but it seems to work just fine for me.

[a-velesov]

+1
so many issues and pull requests have been created, but they are being closed and rejected, and this error is still being repeated. Why?

[niksy]

It seems like first part of the change ("Change the ping to use WebSocket instead of HTTP") is already here

But I’m failing to understand where we should handle WebSocket connection in createWebSocketServer implementation.
From what I can see, that is already handled (vite-ping references).

[sapphi-red]

@niksy What I explained at #5675 (comment) was implemented by #17891

[niksy]

@sapphi-red I’m referencing this situation; it doesn’t seem to work.

What happens is Nodemon restarts whole application (including Vite dev server) and client keeps pinging but after some time it decides to reload whole page instead of using new WebSocket connection.

[sapphi-red]

If the connection is lost and the ping successes later on, Vite will reload the page. This is an intended behavior. Vite cannot just connect the WebSocket, because the Vite cannot know whether the page content that is already loaded is stale or not.

I don't remember why I said "For that case, I think implementing #5675 would work." at #9007 (comment). I should have said "For #9007 (comment)" instead of "For that case".

[mnpenner]

If the connection is lost and the ping successes later on, Vite will reload the page. This is an intended behavior. Vite cannot just connect the WebSocket, because the Vite cannot know whether the page content that is already loaded is stale or not.

So give us some options.

1. Reload the page (like now)
2. Assume it's not stale and attempt to do a hot reload anyway
3. Print a warning to the console that a full page reload is required but do nothing

[niksy]

Assume it's not stale and attempt to do a hot reload anyway

Is this anyhow possible? Like try to create fresh connection and use it for subsequent interactions.

[mnpenner]

Assume it's not stale and attempt to do a hot reload anyway

Is this anyhow possible? Like try to create fresh connection and use it for subsequent interactions.

Dunno. Clearly it's reconnecting if it's forcing a refresh, whether or not that can technically be used for subsequent interactions I'm not sure. Maybe there's some kind of state that's kept in memory and it's flushed when Vite dies so it's not possible. I'm really not sure how the internals work. But if it's not possible, I'd still prefer (3) over (1)

[YowaiCoder]

I'm debugging in webview on iOS and this problem is driving me crazy...