Client pings Server every 1s in case of connection-lost

[ikmrgrv]

Is your feature request related to a problem? Please describe.
Problem message - https://discord.com/channels/804011606160703521/804011606160703524/809370571040882709
The client pings the server every 1000ms (1s) in case of a connection lost.
It leads to a situation like this -

Describe the solution you'd like
We can delay the ping made to the server in case of a web-socket connection lost.
With every failed ping, we can increase the time it waits for the next ping.

Describe alternatives you've considered
We can show a error message in browser itself and let user click on a button to reload. Thus we can avoid pinging server every 1s. This would be a very manual effort though.

Additional context
I guess, this is where we need to modify our code.

[sod]

could also use https://developer.mozilla.org/de/docs/Web/API/Page_Visibility_API to dial back the aggressiveness of checking when in the background, but try to pick up faster if in the foreground.

[yyx990803]

What is really wrong with this? I mean, it logs an error, but is there really any problem this causes?

[ikmrgrv]

What is really wrong with this? I mean, it logs an error, but is there really any problem this causes?

I won't say it's wrong. The code on the client tries to reconnect to the Server, which is good.

But then, as in my case, I closed the Server but the tab in the browser was still open. When I saw the tab again later (in the evening), it was still trying to connect to the server and was ping(ing) backend every 1 second to check for a successful web-socket connection. It was unnecessary code running every second.

I think we can improve this. Instead of checking it every 1 second forever, we can track the no of failed attempts and increase the interval of retry. A similar example is how GMAIL tries to connect back to the server. @sod suggested another technique that would even enhance the delay in retry in the case when the page is in the background.

[airhorns]

I think exponential backoff will give a poor developer experience where the page won't reload in a timely manner when the server does come back. I think that's the point of this reload code -- to have the browser respond to stuff you might be doing in a terminal so you don't have to manually refresh it all the time. If there's a big interval between checks, then the developer will probably beat vite back to the page and the whole feature rendered useless. For this reason I wouldn't call it unnecessary code.

It's also worth noting this only happens in development, it doesn't generate any load in actual production.

[yyx990803]

The point of this retry is so that when you kill and restart the vite server you don't have to manually reload the page. If it doesn't do it promptly then there's not much point in doing it in the first place.

I don't really see a strong argument against this since the page won't be in working state when Vite is disconnected anyway, and errors are going once the page reloads. It is also pinging a dedicated endpoint that shouldn't cause dev server load.

[jcwatson11]

When vite is hosted behind a proxy (apache reverse proxy, for example), the ping process causes the page to entirely reload every second. This is more problematic. While under normal circumstances, I would say this isn't a problem, the reverse proxy situation is common and valid as a use case.

[Shinigami92]

Proposal: What about providing an option for this that takes for example a function / callback as a strategy to wait X seconds for the next attempt. The default is the current behavior.

[FractalHQ]

When using VSCode-Liveshare, this causes a page-refresh every second or so, making it unusable. Is there a way to disable / override this?

[github-actions]

This issue has been locked since it has been closed for more than 14 days.

If you have found a concrete bug or regression related to it, please open a new bug report with a reproduction against the latest Vite version. If you have any other comments you should join the chat at Vite Land or create a new discussion.