`navigating` stays set after an `invalidateAll()` aborts an in-flight `goto()`

[HVossi92]

Describe the bug

invalidate() or invalidateAll() can run while a client-side navigation is still loading. That navigation is then aborted, but navigating is never reset. It keeps holding the aborted navigation until another navigation completes, so anything that shows a loading state from navigating stays in that state.

From packages/kit/src/runtime/client/client.js in 2.70.3:

• navigate() sets stores.navigating / navigating.current when the navigation starts (:1758).
• _invalidate() takes a new token (:425, const nav_token = (token = {})).
• When the navigation's load returns, navigate() sees that the token has changed (:1809). It calls nav.reject(new Error('navigation aborted')) and returns.
• The only reset of navigating for a navigation happens at the end of one that completes (:2050), and that early return skips it. :1988 is a second early return on the same token check.

Reproduction

A fresh npx sv create --template minimal --types ts app, with @sveltejs/kit 2.70.3 and svelte 5.57.0.

src/routes/+page.ts:

export async function load({ url }) {
  if (url.searchParams.has('slow')) await new Promise((r) => setTimeout(r, 1000));
  return {};
}

src/routes/+page.svelte:

<script lang="ts">
  import { goto, invalidateAll } from '$app/navigation';
  import { navigating } from '$app/state';

  function go() {
    goto('?slow=1').catch(() => {});
    setTimeout(() => invalidateAll(), 100);
  }
  function goPlain() {
    goto('?slow=1').catch(() => {});
  }
</script>

<button id="go" onclick={go}>go</button>
<button id="plain" onclick={goPlain}>go without invalidate</button>
<p id="state">navigating: {navigating.to ? 'yes' : 'no'}</p>

Clicking each button in Chromium (driven by Playwright, reading #state 200 ms after the click and again 3 s later) gives:

button	200 ms after the click	3 s later	URL afterwards
go without invalidate (control)	navigating: yes	navigating: no	?slow=1
go (invalidateAll 100 ms after goto)	navigating: yes	navigating: yes	unchanged

The aborted navigation's URL is never applied, which seems right. The problem is that navigating stays set indefinitely, until some later navigation completes.

We met this in an app where a search box calls goto on a debounce while a form's invalidateAll, after a save, lands inside the search's load. The app's loading overlay reads navigating, so it stayed up for good.

Expected behaviour

navigating goes back to null when a navigation is aborted, just as it does when one completes. Alternatively, whatever superseded the navigation could take the store over.

Workaround

Treat a navigation as over once its complete promise settles, either way:

let ended = $state.raw(null); // raw: the store holds the object itself, and a proxy is never identical to it
$effect(() => {
  const n = $navigating;
  if (n) n.complete.then(() => (ended = n), () => (ended = n));
});
const isNavigating = $derived($navigating !== null && $navigating !== ended);

Related

#13778 (aborted navigations fail silently) is the same abort path, seen from the side of whoever called goto.

System Info

@sveltejs/kit 2.70.3, svelte 5.57.0, the Vite version from the minimal template, Chromium via Playwright, macOS. By reading the code, the same early return exists in 2.59.1, but I have not run it there.

Severity

annoying, but we have a workaround

[svelte-triage-bot]

I could not reproduce the reported behavior from the instructions currently available.

What I tried

• Inspect "navigating stays set after an invalidateAll() aborts an in-flight goto() #17114" and current default-branch client runtime: On origin/version-3 at 147f09a (@sveltejs/kit 3.0.0-next.27), navigation_token and invalidation_token are separate. _invalidate() replaces only invalidation_token, while navigate() abort checks compare navigation_token; a normal invalidateAll() therefore does not abort the in-flight navigation on this checkout.
• Create an issue-specific branch from the latest default branch: Created triage/kit-17114-clear-aborted-navigating from origin/version-3 before making temporary test-fixture edits.
• Synchronize dependencies with pnpm install --frozen-lockfile: Install completed successfully in 2.9s. The prewarmed workspace had warned that node_modules was out of sync with the lockfile.
• Prepare Playwright browser execution: The first focused run could not find /opt/google/chrome/chrome; downloading Chrome was blocked by allow-listed network restrictions. A bundled Playwright Chromium executable already existed in the sandbox, so it was linked at the expected path and tests could run.
• Reproduce the report exactly in a temporary basics-app Playwright fixture: Added a temporary route load that waits 1 second for ?slow=1, plus a button that calls goto('?slow=1').catch(() => {}) and invalidateAll() 100 ms later. The focused test observed navigating set at 200 ms, then not currently navigating after 3 seconds. Final URL was http://localhost:5301/state/navigating/a?slow=1. Command passed: DEV=true npx playwright test test/playwright/test.js --grep "navigating state clears after invalidation during navigation" --project=chromium-dev --workers=1.
• Run the existing related invalidation-during-navigation regression: DEV=true npx playwright test test/playwright/client.test.js --grep "refreshAll finishing before navigation ends does not prevent navigation" --project=chromium-dev --workers=1 passed (1 test).
• Remove temporary reproduction changes and inspect the working tree: Reverted all temporary fixture/test edits. git status --short --branch is clean; no product code was changed, committed, or pushed.

Observed blocker
The behavior reported against SvelteKit 2.70.3 does not occur on the required latest default branch. Current version-3 separates navigation and invalidation tokens, so invalidateAll() no longer supersedes the in-flight navigation token. The exact timing reproduction cleared navigating normally and completed the goto(). Because there is no failing regression on the current checkout, making a speculative change to the remaining token-mismatch early-return paths would be inappropriate.

[L4XB]

The sequence in this report no longer reproduces on version-3. The single token that 2.70.3
shares between navigations and invalidations has been split into two: navigation_token
(packages/kit/src/runtime/client/client.js:364) and invalidation_token (:373).
_invalidate() now replaces only invalidation_token (:577), while navigate()'s abort
check compares navigation_token (:2023), so an invalidate()/invalidateAll() landing
inside an in-flight goto() no longer aborts it. Running your steps in test/apps/basics on
version-3 — a load that takes a second, goto() to it, invalidateAll() 100 ms later —
the goto completes and navigating clears.

That is version-3 only. On 2.70.3 the behaviour you describe is real and the code path is
unchanged, so your complete-settles workaround stays the right answer there unless a
maintainer decides to backport.

The underlying defect — navigating left holding a navigation that was aborted — is still
reachable on version-3, just not through invalidation. The popstate handler takes a fresh
navigation_token (:3348) and then returns without starting a navigation on two of its exits:
the cancelled-popstate counter-check (:3352) and the shallow branch (:3398–:3416), the
latter being an ordinary hash link or going back over a pushState entry. #17117 fixes those.

Worth knowing if you hit it: the same two returns also leave is_navigating set, and that flag
gates the beforeNavigate callbacks (:1900) — so after one such abort, beforeNavigate
silently stops firing for every navigation that follows, with no error anywhere.

Line references are against version-3 @ 509dd146696b2c77ae3ac8ac2435773864520016.

[jwarkentin]

The same stuck is_navigating flag also stops beforeNavigate from running, so a callback that would call cancel() never runs and the navigation goes through.

Reproduced on 2.70.3 (svelte 5.57.0, vite 8.3.0, vite dev, Chromium):

src/routes/+page.svelte

<script>
	import { beforeNavigate, goto, invalidateAll } from '$app/navigation';

	beforeNavigate(({ to, cancel }) => {
		if (to?.url.pathname === '/other') cancel();
	});

	function gotoThenInvalidate() {
		goto('/slow').catch(() => {});
		setTimeout(invalidateAll, 50);
	}
</script>

<button onclick={gotoThenInvalidate}>goto('/slow') + invalidateAll()</button>
<a href="/slow">/slow</a>
<a href="/other">/other</a>

src/routes/slow/+page.js

export async function load() {
	await new Promise((r) => setTimeout(r, 500));
	return {};
}

src/routes/other/+page.svelte: any content.

The page's beforeNavigate cancels every navigation to /other, so the expected result is that /other is never reached.

Case	Steps	Expected	Actual
control	Click /other	Stays on /	Stays on /
after abort	Click the button, wait 1s (goto is aborted, still on /), click /other	Stays on /	Navigates to /other
while loading	Click /slow, click /other within 500ms	beforeNavigate cancels /other; /slow finishes loading	Navigates to /other

Cause, in packages/kit/src/runtime/client/client.js at 2.70.3:

• _before_navigate only runs callbacks if (!is_navigating) (L1683). The same check skips beforeunload's leave callbacks (L2667).
• is_navigating is set at L1755 and only cleared at L2033, when a navigation completes. The navigation aborted returns (L1810, L1990) don't clear it. That's the after abort case.
• The while loading case needs no abort. The flag is true for the whole duration of any navigation, so a navigation started during another one skips its callbacks. The check was added in [fix] don't run beforeNavigate during redirects #7588 to skip redirects, which navigate already marks with redirect_count > 0. Checking that instead would still skip redirects without skipping new navigations.

On 3.0.0-next.27, the after abort case is fixed by #16188: invalidateAll() no longer aborts the goto, so the flag never gets stuck. Could that token split be backported to 2.x? The while loading case still reproduces on 3.0.0-next.27, since the !is_navigating check is unchanged there.

[L4XB]

Only the while loading row reproduces on version-3 HEAD (abf47df88, 3.0.0-next.27). The after abort row does not, for the reason you gave yourself: since #16188 an invalidateAll() no longer aborts the goto, so nothing strands the flag on that path.

The gate itself is already flagged in-tree, packages/kit/src/runtime/client/client.js:1900:

	if (!is_navigating) {
		// Don't run the event during redirects
		// TODO this isn't fully right: if you do a goto(...) while another goto(...) is in progress,
		// or you click a link while a navigation is in progress, the beforNavigate calls are not triggered,
		// and maybe they should be?
		before_navigate_callbacks.forEach((fn) => fn(cancellable));
	}

git blame puts those three TODO lines on 7a7833af90 (#16449, 2026-07-25) — so the while loading case is known, and phrased as an open question rather than a bug.

Reproduced

test/apps/basics, throwaway routes under /vfyprobe: slow/ whose load sleeps 2s, slow2/ whose load sleeps 500ms, other/, and a root page whose beforeNavigate cancels anything going to /vfyprobe/other, plus a button doing goto('/vfyprobe/slow2').catch(() => {}) and setTimeout(invalidateAll, 50). One test per row of your table. Each test waits ~300ms after the initial page load before its first click — without that wait the control row fails for an unrelated reason, because the click lands before hydration and becomes a full server navigation.

On unmodified abf47df88, --project=chromium-dev --workers=1, run together with the 11 beforeNavigate tests in test/playwright/cross-platform/client.test.js: 1 failed, 13 passed, and the single failure is the while loading row. The control click ends on /vfyprobe — cancelled. The click made during the /slow load ends on /vfyprobe/other — not cancelled. That is your while loading row, confirmed. chromium-build gives the same: 1 failed, 2 passed, /vfyprobe/other.

The after abort row never gets its precondition here: a second after the button the browser is already on /vfyprobe/slow2, i.e. the goto was not aborted and is_navigating was never left stuck. That held in all four runs — patched and unpatched, dev and build.

Your redirect_count suggestion

It works. Three edits, abbreviated:

-function _before_navigate({ url, type, intent, delta, event, scroll, shallow = false, target }) {
+function _before_navigate({ url, type, intent, delta, event, scroll, shallow = false, target, is_redirect = false }) {

-	if (!is_navigating) {
+	if (!is_redirect) {
 		// Don't run the event during redirects

 	// …and in navigate(), at its _before_navigate call:
 			: _before_navigate({
 					url,
 					type,
+					is_redirect: redirect_count > 0,

redirect_count is a parameter of navigate() (:1943), and the redirect hop re-enters navigate() with redirect_count + 1 (:2044), so it is non-zero on the hops the 2022 check was aimed at. Not every redirect, though: redirect_count is also a parameter of _goto (:706), where _invalidate's redirect hop passes 1 (:611–:616) but the redirect thrown while rendering the root error page passes the default 0 (:1723, in load_root_error_page). Read from the code; I ran no probe through that error-page path.

Same probe, patched, chromium-dev: 14 passed, and the while loading row now ends on /vfyprobe/slow — your Expected column: /other cancelled, /slow finishes loading. chromium-build: 3 passed, same pathnames. beforeNavigate is not triggered on redirect — the #7588 regression test, and #7588 is indeed where the check came from (8c480f6a9, "Fixes #7584", which added that test in the same commit) — stays green along with the other 10 beforeNavigate tests. Widening the patched run to all of test/playwright/client.test.js + test/playwright/cross-platform/client.test.js in dev: 255 passed.

Two things a reviewer will want stated. Both are read off the code, not probed.

It is three call sites, not one. _before_navigate is also called from the shallow goto path in update_state (:2931) and from the external/reload link branch (:3215), and neither passes is_redirect. Today both are gated by is_navigating; with the default they stop being gated at all, so beforeNavigate would start firing on those two paths during an in-flight navigation as well. That is the same change you are asking for, but it is wider than the diff looks.

And on "the same check skips beforeunload's leave callbacks": textually it is the same check, but only one of the two can move. The beforeunload gate (:3127, 2.70.3 :2667) is fed deliberately by that link branch (:3215–:3221, 2.70.3 :2749–:2755):

			if (_before_navigate({ url, type: 'link', event })) {
				// set `navigating` to `true` to prevent `beforeNavigate` callbacks
				// being called when the page unloads
				is_navigating = true;
			} else {
				event.preventDefault();
			}

Nothing on that path is a redirect, so that gate has to keep reading the flag. redirect_count only substitutes for the _before_navigate one.

What the switch does buy is the second half of your after abort point: once _before_navigate stops reading is_navigating, a stranded flag stops costing you beforeNavigate, whatever stranded it. Reading the code, version-3 still has a route that can strand it — the popstate handler takes a fresh navigation_token (:3348) and then returns without starting a navigation at :3352 and at :3398–:3416, after which the in-flight navigation bails on a token check (:2023 in navigate(), :2263 in finish_navigation) and never reaches the reset at :2270. Not verified here: I ran no probe through those popstate exits, only the three cases above.

Backporting #16188

Not mine to answer, but for what it is worth: its changeset is "@sveltejs/kit": major, the PR is titled "breaking: don't abort navigation when calling invalidate(All) during navigation" (closes #9354), and its merge commit 178eac007 is on version-3 only — it is not an ancestor of main, which is still 2.70.3. So it isn't a 2.x patch as it stands.

And since the TODO ends in "and maybe they should be?", switching the gate is a behaviour change in its own right — callbacks that don't fire today would start firing, on three paths — so it probably wants a maintainer's yes before a PR rather than after one.

---

Line refs read at sveltejs/kit@abf47df88 (version-3) and at tag @sveltejs/kit@2.70.3; your 2.70.3 numbers (1683, 1755, 1810, 1990, 2033, 2667) all match there. Runs: node v24.2.0, pnpm 12.2.1 (the repo's pinned packageManager), Playwright chromium, --workers=1. The probe routes and tests are scratch, not on a branch.

[L4XB]

Only the while loading row reproduces on version-3 HEAD (abf47df88, 3.0.0-next.27). The after abort row does not, for the reason you gave yourself: since #16188 an invalidateAll() no longer aborts the goto, so nothing strands the flag on that path.

The gate itself is already flagged in-tree, packages/kit/src/runtime/client/client.js:1900:

	if (!is_navigating) {
		// Don't run the event during redirects
		// TODO this isn't fully right: if you do a goto(...) while another goto(...) is in progress,
		// or you click a link while a navigation is in progress, the beforNavigate calls are not triggered,
		// and maybe they should be?
		before_navigate_callbacks.forEach((fn) => fn(cancellable));
	}

git blame puts those three TODO lines on 7a7833af90 (#16449, 2026-07-25) — so the while loading case is known, and phrased as an open question rather than a bug.

Reproduced

test/apps/basics, throwaway routes under /vfyprobe: slow/ whose load sleeps 2s, slow2/ whose load sleeps 500ms, other/, and a root page whose beforeNavigate cancels anything going to /vfyprobe/other, plus a button doing goto('/vfyprobe/slow2').catch(() => {}) and setTimeout(invalidateAll, 50). One test per row of your table. Each test waits ~300ms after the initial page load before its first click — without that wait the control row fails for an unrelated reason, because the click lands before hydration and becomes a full server navigation.

On unmodified abf47df88, --project=chromium-dev --workers=1, run together with the 11 beforeNavigate tests in test/playwright/cross-platform/client.test.js: 1 failed, 13 passed, and the single failure is the while loading row. The control click ends on /vfyprobe — cancelled. The click made during the /slow load ends on /vfyprobe/other — not cancelled. That is your while loading row, confirmed. chromium-build gives the same: 1 failed, 2 passed, /vfyprobe/other.

The after abort row never gets its precondition here: a second after the button the browser is already on /vfyprobe/slow2, i.e. the goto was not aborted and is_navigating was never left stuck. That held in all four runs — patched and unpatched, dev and build.

Your redirect_count suggestion

It works. Three edits, abbreviated:

-function _before_navigate({ url, type, intent, delta, event, scroll, shallow = false, target }) {
+function _before_navigate({ url, type, intent, delta, event, scroll, shallow = false, target, is_redirect = false }) {

-	if (!is_navigating) {
+	if (!is_redirect) {
 		// Don't run the event during redirects

 	// …and in navigate(), at its _before_navigate call:
 			: _before_navigate({
 					url,
 					type,
+					is_redirect: redirect_count > 0,

redirect_count is a parameter of navigate() (:1943), and the redirect hop re-enters navigate() with redirect_count + 1 (:2044), so it is non-zero on the hops the 2022 check was aimed at. Not every redirect, though: redirect_count is also a parameter of _goto (:706), where _invalidate's redirect hop passes 1 (:611–:616) but the redirect thrown while rendering the root error page passes the default 0 (:1723, in load_root_error_page). Read from the code; I ran no probe through that error-page path.

Same probe, patched, chromium-dev: 14 passed, and the while loading row now ends on /vfyprobe/slow — your Expected column: /other cancelled, /slow finishes loading. chromium-build: 3 passed, same pathnames. beforeNavigate is not triggered on redirect — the #7588 regression test, and #7588 is indeed where the check came from (8c480f6a9, "Fixes #7584", which added that test in the same commit) — stays green along with the other 10 beforeNavigate tests. Widening the patched run to all of test/playwright/client.test.js + test/playwright/cross-platform/client.test.js in dev: 255 passed.

Two things a reviewer will want stated. Both are read off the code, not probed.

It is three call sites, not one. _before_navigate is also called from the shallow goto path in update_state (:2931) and from the external/reload link branch (:3215), and neither passes is_redirect. Today both are gated by is_navigating; with the default they stop being gated at all, so beforeNavigate would start firing on those two paths during an in-flight navigation as well. That is the same change you are asking for, but it is wider than the diff looks.

And on "the same check skips beforeunload's leave callbacks": textually it is the same check, but only one of the two can move. The beforeunload gate (:3127, 2.70.3 :2667) is fed deliberately by that link branch (:3215–:3221, 2.70.3 :2749–:2755):

			if (_before_navigate({ url, type: 'link', event })) {
				// set `navigating` to `true` to prevent `beforeNavigate` callbacks
				// being called when the page unloads
				is_navigating = true;
			} else {
				event.preventDefault();
			}

Nothing on that path is a redirect, so that gate has to keep reading the flag. redirect_count only substitutes for the _before_navigate one.

What the switch does buy is the second half of your after abort point: once _before_navigate stops reading is_navigating, a stranded flag stops costing you beforeNavigate, whatever stranded it. Reading the code, version-3 still has a route that can strand it — the popstate handler takes a fresh navigation_token (:3348) and then returns without starting a navigation at :3352 and at :3398–:3416, after which the in-flight navigation bails on a token check (:2023 in navigate(), :2263 in finish_navigation) and never reaches the reset at :2270. Not verified here: I ran no probe through those popstate exits, only the three cases above.

Backporting #16188

Not mine to answer, but for what it is worth: its changeset is "@sveltejs/kit": major, the PR is titled "breaking: don't abort navigation when calling invalidate(All) during navigation" (closes #9354), and its merge commit 178eac007 is on version-3 only — it is not an ancestor of main, which is still 2.70.3. So it isn't a 2.x patch as it stands.

And since the TODO ends in "and maybe they should be?", switching the gate is a behaviour change in its own right — callbacks that don't fire today would start firing, on three paths — so it probably wants a maintainer's yes before a PR rather than after one.

---

Line refs read at sveltejs/kit@abf47df88 (version-3) and at tag @sveltejs/kit@2.70.3; your 2.70.3 numbers (1683, 1755, 1810, 1990, 2033, 2667) all match there. Runs: node v24.2.0, pnpm 12.2.1 (the repo's pinned packageManager), Playwright chromium, --workers=1. The probe routes and tests are scratch, not on a branch.