use_navigate and Firefox network.http.max-persistent-connections-per-server

[emirror-de]

I have a leptos 0.5 app with strange behavior when using use_navigate. Every route does between 1 and 5 requests using reqwest when opened.

When switching fast between the routes, the app gets stuck on the 7th route change. All network requests are loading but never return. The first request that is done is marked as blocked by Firefox.

I found this on the web: https://stackoverflow.com/questions/43783829/what-does-blocked-really-mean-in-the-firefox-developer-tools-network-monitorin

This took me to the Firefox network.http.max-persistent-connections-per-server setting which is 6 per default. Increasing this value to eg. 10, the leptos app gets stuck at the 11th route change.

So to me it seems, that leptos is making a new connection to the server on every route change, but not reusing already created ones? At least there seems to be a connection between the value of the setting in Firefox and route changes in leptos.

Are there any tricks or pitfalls with use_navigate that I need to consider to prevent this behavior? What am I doing wrong?

I also tested with gloo for the requests, but there is no difference.

[gbj]

leptos is making a new connection to the server on every route change
Isn't it that you are making a new connection to the server on every route change using reqwest?

but not reusing already created ones
I'm not really sure what this means.

Are there any tricks or pitfalls with use_navigate that I need to consider to prevent this behavior? What am I doing wrong?

use_navigate just navigates, on the client side (ie in the browser), between the components you've associated with different routes. It sounds like you are navigating to 5 different routes, each of which makes a request using reqwest, but that none of those requests resolve before you try the 6th navigation, which means it fails.

A good example of how to handle this better would be to cancel in-flight requests using the browser's AbortSignal/AbortController API, so that when you navigate away from a page the request you made from that page is canceled. Here's an example

leptos/examples/hackernews/src/api.rs

Lines 12 to 38 in 17b3300

	#[cfg(not(feature = "ssr"))]
	pub async fn fetch_api<T>(path: &str) -> Option<T>
	where
	T: Serializable,
	{
	let abort_controller = web_sys::AbortController::new().ok();
	let abort_signal = abort_controller.as_ref().map(|a| a.signal());
	// abort in-flight requests if, e.g., we've navigated away from this page
	leptos::on_cleanup(move || {
	if let Some(abort_controller) = abort_controller {
	abort_controller.abort()
	}
	});
	let json = gloo_net::http::Request::get(path)
	.abort_signal(abort_signal.as_ref())
	.send()
	.await
	.map_err(|e| log::error!("{e}"))
	.ok()?
	.text()
	.await
	.ok()?;
	T::de(&json).ok()
	}

[emirror-de]

Hey, thanks for your response!

I double checked the behavior based on your response and integrated the lines from your example, but found no change in behavior. As I updated a few days ago to leptos 0.5 I also checked out an earlier version that runs with leptos 0.4 and noticed that the problem also occurs. So in conclusion this behavior seems not to be related to leptos, in contrast to what I was thinking initially.

This is also hardened by the fact that I cannot reproduce the issue on Chromium, so could be a Firefox related issue. I also found this issue for hyper but the reports are not belonging to the wasm target (I am using axum on the server side, but I am also not sure if thats a dead end because the logs on server side are telling that the latest wav request is successfully resolved).

The requests that are done on every route change are finished before the navigation switch is being initiated. The screenshot shows the network tab that with the requests done. Requests with status 200 are before the route change. The wav file is requested using the native <audio> element with a change of src done by a memo (I double checked, and it is definitely executed once on change.
Audio and image files are served by a ServeDir oneshot call as I am required to do a few more things before the actual data gets served.

(For clarification, the first *png calls already solved with status 200 are json requests and responses, the not resolving ones are png files, so there are no doubled requests as seems at first look)

I am happy for any hints or ideas on this.

[gbj]

No idea what the issue could be then. Any chance you can provide any kind of reproducible example?

[emirror-de]

I'm trying to create a simplified one, but no luck yet. I'll post it as soon as I can reproduce it.

[emirror-de]

I was not able to create a simple example yet, but it seems that this is a browser related issue. It does only occur on Firefox, Chromium Browsers somehow do not show this kind of behavior.