The "Connection to server has been lost" behaves oddly, doesn't handle reconnections

Hi!

So, we all probably have seen that "Connection to server has been lost" dialog on the bottom-right of the screen. It stays there until interacted with.

I was trying to get rid of it and/or improve the behavior, but it's honestly just left me with confusion...

For reference, here's the code that spawns the dialog: https://activitypub.software/TransFem-org/Sharkey/-/blob/develop/packages/frontend/src/boot/main-boot.ts?ref_type=heads#L48

So, when the "disconnected" event is received (corresponding to a "close" event on the websocket), this dialog pops up, and stays there until interacted.

There are some points I'm confused by:

• That dialog sometimes seemed to just semi-permanently reside on my screen at times, other times it's gone.
• The "disconnected" event never seems to fire, even when I kill the network connection. The heartbeats don't seem to do much, there.
• The confirm() function discards the "dispose" function, so even if the websocket reconnects (which it might; it uses ReconnectingWebsocket), the dialog just kinda stays there.

Instead, I propose something like thist:

// A reference to the function to close the "reconnecting" dialog; null if the dialog is not open.
let reloadDialogDisposeFn : Function | null = null;

// When the stream is disconnected, show a dialog to reload the page.
stream.on('_disconnected_', async () => {
	// TODO: Where's that setting?
	if (defaultStore.state.serverDisconnectedBehavior === 'dialog') {

		// If the dialog is already open, do nothing.
		if (reloadDialogDisposeFn) return;

		// Show a popup dialog with a warning message and a "reload" button.
		const {dispose} = popup(MkDialog, {
			...({
				type: 'warning',
				title: i18n.ts.disconnectedFromServer,
				text: i18n.ts.reloadConfirm,
			}),
			showCancelButton: true, // Show a "cancel" button; this dismisses the dialog without reloading the page.
		}, {
			// If the user clicks one of the buttons, and it's the "positive" button (in this case, the "reload" button),
			done: result => {
				if (!result) location.reload();
			},
			// If the dialog is closed, dispose of the dialog.
			closed: () => dispose(),
		});

		// Save the function to close the dialog so that it can be called later.
		reloadDialogDisposeFn = dispose;
	}
});

// When the stream is (re)connected, close the "reconnecting" dialog if it's open.
stream.on('_connected_', () => {
	if (reloadDialogDisposeFn) {
		reloadDialogDisposeFn();
		reloadDialogDisposeFn = null;
		toast("Reconnected to server.");
	}
});

But... I'm having trouble testing it, since that "disconnect" event never even seems to fire, even with the connection cut.

What's going on here? Are we trying to handle accidental disconnections? Server shutdowns?

changed title from What's is the purpose of the "Connection to server has been lost" dialog? to The "Connection to server has been lost" behaves oddly, doesn't handle reconnections

From what I can tell with WebSocket, heartbeats are a fairly manual affair... You send heartbeats and wait on timeouts yourself. "onclose" isn't particularly trigger-happy on a regular failed connection.

State is still "connected" on a browser tab that's been without network for like 20 minutes now.

For reference, there's nothing handling the 'h' heartbeat messages here:

https://activitypub.software/TransFem-org/Sharkey/-/blob/develop/packages/backend/src/server/api/stream/Connection.ts?ref_type=heads#L153

If the expectation is that sending the 'h' messages might trigger the WebSocket's onclose event if it's not connected... It at least doesn't appear to work on Firefox 132.

Given that there's a heartbeat involved, I think I'll assume it's to try to detect broken connections and work on a fix under that assumption

added bugfrontend label

Ok, just killed my WiFi, I am now even more confused about what's going on, as this is what show up in my dev tools...

Does sending 'h' trigger the browser to notice a disconnect after all? But then why doesn't the dialog not show up? (Could it have something to do with my old server being less stable somehow and actually fully closing the connections sometimes?)

Beginning to suspect that the webdev tools connection simulator might not be accurate on Firefox, as I saw new notes appearing even with it set to "offline". I guess I'll just turn off my wifi to test it instead?

EDIT: Weirdly enough, this appears to be a bug in Chromium (https://issues.chromium.org/issues/41483836 and https://issues.chromium.org/issues/40389053) yet I'm using firefox?

Yup, confirmed bug in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1421357

This post is relevant for testing as well: https://forums.meteor.com/t/how-to-effectively-simulate-offline-mode-in-dev-mode/47467/12

It adds a DROP rule to iptables to simulate a network failure where the packets just disappear, as opposed to the network actually being offline in a way the client computer's network stack can readily detect.

Solution is probably to implement heartbeats manually; I'll be doing that

The heartbeats were being sent like this:

	public heartbeat(): void {
		this.stream.send('h');
	}

For the record, this does nothing server-side, it just gets quietly dropped because it's not valid JSON.

                try {
			obj = JSON.parse(data.toString());
		} catch (e) {
			return;
		}

I added a console.err there.

thank you for the investigation!

we have also been pretty confused about the whole websocket / connection / heartbeat logic, and that's why we've not tried to do much about it. "it works enough"

please keep us informed of any further details you uncover!