[Bug]: Stream timeline doesn't refresh after the sleep of the computer

[lapor-kris]

Describe the bug

After sleep of the computer (Fedora 37), the stream timeline (home) doesn't get refreshed. As if the connection is lost.

Steps To Reproduce

1. Open Tuba
2. put the computer to sleep (close the lid)
   3.wake the computer (open the lid)
3. check the Tuba app (the stream is not refreshed)

Logs and/or Screenshots

<paste your logs here>

Instance Backend

Mastodon

Operating System

Fedora 37

Package

Flatpak

Troubleshooting information

If I force quit the app through the System monitor in Gnome and open the app again, it works.

Additional Context

No response

[jdkruzr]

confirmed. also made me wonder why there is no "refresh" button!

[nekohayo]

Possibly related: #204

[ckruse]

@jdkruzr there is now refresh button, but you can hit ctrl+r to reload

[primalmotion]

where is that refresh button? I don't see it on mobile

[GeopJr]

main has pull to refresh, I'll make a new release soon enough after fixing some more issues!

[primalmotion]

awesome! thanks!

[primalmotion]

additional question, pull to refresh is nice to have, but is just a workaround to the connection loss after sleeping. I think it should eventually be fixed, but the question is: after pulling to refresh, will the push channel recover?

[GeopJr]

Nope it won't. (Well, if it's part of a non-main timeline, you can go back and re-open it and it will re-establish a websocket connection)

This issue has some wider problems:

1. It's not that easy to reliably reproduce, sometimes it reconnects, sometimes it doesn't disconnect at all (for me at least)
2. It might be a network connectivity issue. If a connection closes from the server, Tuba will keep retrying to connect every x seconds but that's as long as websocket_connect_async does not error. It could error for several reasons, one of them being lack of internet access (probably the cause of this issue) and the solution to that involves [Bug]: Should check for full network connectivity using NetworkManager before attempting anything #204 (do we keep trying forever? do we create a queue and process it when there's internet connection again?)

I suppose a middle ground of checking if there's an active websocket connection on refresh (and connecting) is probably a quick temp solution for this

[primalmotion]

hum. I had this kind of problem with long lasting websockets. the fix I did was to enable ping control frames. the client sends regular control frames (ping) and has a timeout waiting for a pong. passed that, the connection will be considered as lost. I did that in go, not sure how that translates in vala :) any respectable server implementation should reply to pings

[GeopJr]

Your insight would be much appreciated, here's what's going on:
libsoup should handle pinging / keeping the connection alive. The connection happens here:

Tuba/src/Services/Network/Streams.vala

Lines 67 to 80 in 57b480b

	public bool start () {
	message (@"Opening stream: $name");
	network.session.websocket_connect_async.begin (msg, null, null, 0, null, (obj, res) => {
	try {
	socket = network.session.websocket_connect_async.end (res);
	socket.error.connect (on_error);
	socket.closed.connect (on_closed);
	socket.message.connect (on_message);
	} catch (Error e) {
	warning (@"Error opening stream: $(e.message)");
	}
	});
	return false;
	}

when closed is emitted, the following function gets called and if it wasn't closed by us, it reconnects by calling the previous function:

Tuba/src/Services/Network/Streams.vala

Lines 110 to 117 in 57b480b

	void on_closed () {
	if (!closing) {
	warning (@"DISCONNECTED: $name. Reconnecting in $timeout seconds.");
	GLib.Timeout.add_seconds (timeout, start);
	timeout = int.min (timeout * 2, 6);
	}
	message (@"Closing stream: $name");
	}

My speculation - without having debugged this issue further - is that the connection closes at some point and while reconnecting, it fails, resulting in never connecting to the closed event again and therefore never attempting to reconnect again

Tuba/src/Services/Network/Streams.vala

Lines 75 to 77 in 57b480b

	} catch (Error e) {
	warning (@"Error opening stream: $(e.message)");
	}

Let me know if you notice anything but this definitely needs further debugging

[primalmotion]

I think what's happenning is that the client never notices the fact that the connection has been closed on the other side. It should be aware of it, but I've seen many cases where is does not for some reasons, thinking it's connected while it's not. It won't realize until you actually send a message. I suspect in Tuba, we never send anything through the websocket, and the client does not realize nobody's on the other side of the line.

I'm unfamilliar with libsoup, but this https://developer-old.gnome.org/libsoup/stable/libsoup-2.4-WebSockets.html#SoupWebsocketConnection--keepalive-interval seems to be related to pings and it defaults to 0, meaning disabled. I'm not sure if setting it to non-zero would actually make it send ping control frame though

EDIT: according to that documentation https://libsoup.org/libsoup-3.0/property.WebsocketConnection.keepalive-interval.html it seems to say that this is enough to enable pings, but does not state the default value :) Documentation, you gotta love it :)

[GeopJr]

Thanks for the info! The default value seems to be 0 https://gitlab.gnome.org/GNOME/libsoup/-/blob/master/libsoup/websocket/soup-websocket-connection.c#L1625

I set it to 30 seconds 4f54605. I'm a bit hesitant to close this issue however, I'll leave it open for future comments

[primalmotion]

Great! I'll give it a try once the flatpak build is done and report back

[primalmotion]

it seems to work! if I suspend for less than 30s, I don't see the disconnection warning. if it's more than 30s, i see it and it reconnects

[GeopJr]

Awesome, thanks for the solution and testing!

If starts happening again, let me know and I'll re-open this issue!

[nekohayo]

This still happens with version 0.4.0 from flathub. I closed the lid of my laptop for roughly 25 minutes, during which it was suspended, and then reopened the lid. Tuba did not refresh the home timeline with the posts that happened during the suspended time, whereas there were new posts according to the Mastodon web interface. However, after resuming, future posts get added to Tuba's home timeline automatically. In other words, it is missing the middle, the posts during sleep. Doing a forced refresh with Ctrl+R shows those missing in-between posts...

These are the terminal output messages upon resume from suspend:

(dev.geopjr.Tuba:2): Tuba-WARNING **: 00:02:59.262: Streams.vala:109: Error in https://streaming.mastodon.social/api/v1/streaming?stream=direct: Error receiving data: Connection reset by peer

(dev.geopjr.Tuba:2): Tuba-WARNING **: 00:02:59.262: Streams.vala:114: DISCONNECTED: https://streaming.mastodon.social/api/v1/streaming?stream=direct. Reconnecting in 1 seconds.
Tuba-Message: 00:02:59.262: Streams.vala:118: Closing stream: https://streaming.mastodon.social/api/v1/streaming?stream=direct

(dev.geopjr.Tuba:2): Tuba-WARNING **: 00:02:59.654: Streams.vala:109: Error in https://streaming.mastodon.social/api/v1/streaming?stream=user:notification: Error receiving data: Connection reset by peer

(dev.geopjr.Tuba:2): Tuba-WARNING **: 00:02:59.654: Streams.vala:114: DISCONNECTED: https://streaming.mastodon.social/api/v1/streaming?stream=user:notification. Reconnecting in 1 seconds.
Tuba-Message: 00:02:59.655: Streams.vala:118: Closing stream: https://streaming.mastodon.social/api/v1/streaming?stream=user:notification
Tuba-Message: 00:03:00.440: Streams.vala:68: Opening stream: https://streaming.mastodon.social/api/v1/streaming?stream=direct
Tuba-Message: 00:03:00.440: Streams.vala:68: Opening stream: https://streaming.mastodon.social/api/v1/streaming?stream=user:notification

(dev.geopjr.Tuba:2): Tuba-WARNING **: 00:03:04.431: Streams.vala:109: Error in https://streaming.mastodon.social/api/v1/streaming?stream=user:notification: Error receiving data: Connection reset by peer

(dev.geopjr.Tuba:2): Tuba-WARNING **: 00:03:04.432: Streams.vala:114: DISCONNECTED: https://streaming.mastodon.social/api/v1/streaming?stream=user:notification. Reconnecting in 1 seconds.
Tuba-Message: 00:03:04.432: Streams.vala:118: Closing stream: https://streaming.mastodon.social/api/v1/streaming?stream=user:notification

(dev.geopjr.Tuba:2): Tuba-WARNING **: 00:03:04.456: Streams.vala:109: Error in https://streaming.mastodon.social/api/v1/streaming?stream=user:notification: Error receiving data: Connection reset by peer

(dev.geopjr.Tuba:2): Tuba-WARNING **: 00:03:04.457: Streams.vala:114: DISCONNECTED: https://streaming.mastodon.social/api/v1/streaming?stream=user:notification. Reconnecting in 1 seconds.
Tuba-Message: 00:03:04.457: Streams.vala:118: Closing stream: https://streaming.mastodon.social/api/v1/streaming?stream=user:notification

(dev.geopjr.Tuba:2): Tuba-WARNING **: 00:03:04.458: Streams.vala:109: Error in https://streaming.mastodon.social/api/v1/streaming?stream=user:notification: Error receiving data: Connection reset by peer

(dev.geopjr.Tuba:2): Tuba-WARNING **: 00:03:04.458: Streams.vala:114: DISCONNECTED: https://streaming.mastodon.social/api/v1/streaming?stream=user:notification. Reconnecting in 1 seconds.
Tuba-Message: 00:03:04.458: Streams.vala:118: Closing stream: https://streaming.mastodon.social/api/v1/streaming?stream=user:notification

(dev.geopjr.Tuba:2): Tuba-WARNING **: 00:03:04.461: Streams.vala:109: Error in https://streaming.mastodon.social/api/v1/streaming?stream=user: Error receiving data: Connection reset by peer

(dev.geopjr.Tuba:2): Tuba-WARNING **: 00:03:04.461: Streams.vala:114: DISCONNECTED: https://streaming.mastodon.social/api/v1/streaming?stream=user. Reconnecting in 1 seconds.
Tuba-Message: 00:03:04.461: Streams.vala:118: Closing stream: https://streaming.mastodon.social/api/v1/streaming?stream=user
Tuba-Message: 00:03:05.439: Streams.vala:68: Opening stream: https://streaming.mastodon.social/api/v1/streaming?stream=user:notification
Tuba-Message: 00:03:05.439: Streams.vala:68: Opening stream: https://streaming.mastodon.social/api/v1/streaming?stream=user:notification
Tuba-Message: 00:03:05.439: Streams.vala:68: Opening stream: https://streaming.mastodon.social/api/v1/streaming?stream=user:notification
Tuba-Message: 00:03:05.439: Streams.vala:68: Opening stream: https://streaming.mastodon.social/api/v1/streaming?stream=user