navigate() from flight-data consumer can silently drop a relative-Location redirect (reliable with absolute URLs)

[sparklog]

Summary

A redirect() thrown (or returned) from a server-function action with a relative target (Location: /) sometimes fails to navigate at all on the client — no error, no console output, no URL change — while the action response itself is perfectly valid and the single-flight query cache still updates. Sending the identical redirect as a same-origin absolute URL (Location: http://localhost:3000/) navigates reliably 100% of the time.

Versions:

• @solidjs/router@2.0.0-next.18
• @solidjs/web@2.0.0-rc.3
• Solid 2.0.0-rc.3 (streaming SSR)

Reproduction

A login/register/logout implemented as a server-function action:

export const login = action(async (formData: FormData) => {
  'use server';
  // …validate, hash, setSession({ userId })…
  throw redirect('/'); // relative → SOMETIMES does not navigate
});

Observed wire response (identical whether the redirect is thrown or returned):

HTTP/1.1 200 OK
location: /
x-server-function-error: true
x-server-function-format: 0
x-single-flight: true
set-cookie: session=…; HttpOnly; Max-Age=604800; Path=/; SameSite=Lax; Secure

Expected: the client navigates to / after the action settles.

Actual: in some environments/browsers the page never navigates. A manual refresh reveals the correct state (the cookie was set server-side, and the single-flight data did update the query cache) — only the URL never moves. There are no console errors. In our reproduction environment (real headless Chrome, both dev and production builds) navigation succeeded, while a user's browser hit the failure consistently, so it is timing/environment-sensitive.

The same action with an absolute target always works:

throw redirect(new URL(path, getRequestEvent()!.request.url).toString()); // works reliably

Root-cause analysis

The client-side redirect policy is identical between the old @solidjs/router@0.14/0.15 (SolidStart 1.x era) and v2 — both do:

if (locationUrl.startsWith("http")) {
  window.location.href = locationUrl;   // hard navigation — reliable
} else {
  navigate(locationUrl);                 // soft navigation
}

The difference is the soft-navigation engine. The old router committed inside startTransition(() => setReference(...)) with a guaranteed .finally() teardown. The v2 router commits via setNavigateTarget(...) plus a cancelable queueMicrotask (@solidjs/router/dist/index.js, navigateFromRoute):

intent = "navigate";
lastTransitionTarget = newTarget;
if (firstNavigation) { setIsRouting(true); flush(); }
if (lastTransitionTarget === newTarget) {
  setNavigateTarget({ ...lastTransitionTarget });
  queueMicrotask(() => {
    if (lastTransitionTarget !== newTarget) return; // ← silently skips the URL commit
    intent = undefined;
    navigateEnd(lastTransitionTarget);
    setNavigateTarget(undefined);
    setIsRouting(false);
    lastTransitionTarget = undefined;
  });
}

If lastTransitionTarget is overwritten by a second navigation between setNavigateTarget and the microtask — or if a Solid 2 transition/flush scheduling interaction interferes — the URL commit is silently dropped. Additionally, for action redirects the navigate() call now originates from inside the flight-data consumer (setupFlightDataConsumer → applyResponseMetadata), i.e. before the action settles, which puts the navigation in a different async/timing window than the old router (which navigated from the action's settled handler).

Questions

1. Is the lastTransitionTarget === newTarget guard in the microtask intended to silently drop superseded navigations? If so, is silently dropping a server-initiated redirect acceptable without any fallback (e.g. a hard location.assign to the last target)?
2. Should redirects with a relative Location that originate from server functions prefer the hard branch (window.location.assign(new URL(locationUrl, location.href))), reserving soft navigation for same-document UI navigations?
3. Is there a known interaction between Solid 2's "every write is a transition" model and calling navigate() from inside the flight-data consumer (pre-settle) that could make the microtask commit unreliable under certain hydration/timing conditions?

Expected behavior

A relative redirect from a server-function action should either navigate (soft or hard) or fail loudly — never silently do nothing while the cookie/data update succeeded.

---

• Environment: Solid 2.0 rc, streaming SSR, @solidjs/server-functions transport with single-flight enabled.
• Workaround currently shipped in our codebase: emit the redirect target as a same-origin absolute URL; verify before merging any opinionated fix.
• Happy to provide a minimal repro repo or to bisect with a specific browser/timing setup if useful.

[ryansolid]

The carrier half landed: server-function redirects now arrive as X-Server-Function-Redirect: <status> <resolved-url> (006a115), and the router navigates from an origin comparison on that resolved url with replace: true (solidjs/solid-router@033b6f1) — relative and absolute spellings take the same path by construction, which removes the workaround asymmetry you shipped.

Keeping this open for the underlying soft-navigation reliability question: the cancelable queueMicrotask commit in navigateFromRoute (your question 1) needs a reproducing test before touching the scheduling — reading the supersede paths hasn't produced the mechanism yet, and your own repro attempts suggest it is timing-sensitive. If you can share the browser/timing setup where it reproduced consistently, that would shortcut the investigation considerably.

[sparklog]

Thanks — took your suggestion, upgraded, and captured a fresh before/after comparison on this version (solid-js/@solidjs/web 2.0.0-rc.4,
@solidjs/router 2.0.0-next.19, workerd preview + D1, real headless Chrome, login action submitted to /_server/):

Absolute spelling — redirect(new URL("/", req.url).toString()):
HTTP 200, location: http://localhost:4173/, x-single-flight: true, x-server-function-error: true
-> locationUrl.startsWith("http") true -> window.location.href (hard navigation) -> navigates to /, signed in.

Relative spelling — redirect("/"):
HTTP 200, location: /, x-single-flight: true, x-server-function-error: true
-> startsWith("http") false -> navigate("/") (soft navigation) -> navigated here too, but only because my environment cannot reproduce the silent failure.

So on this npm release the masked redirect still arrives as Location on a 200, and applyResponseMetadata still picks the navigation strategy from the string shape of that header. The X-Server-Function-Redirect carrier (006a115 / 033b6f1) has not landed on npm yet, so I kept the same-origin absolute-URL workaround and documented its removal condition in the helper's doc comment.

Other updates from the upgrade: server-function addressing changed to /_server/ (was /_server?id=…), tests updated accordingly; leftover debug log removed. 53 tests green across client/server/workers; login/register/logout + inline error verified end-to-end in headless Chrome.

On the open soft-navigation reliability question: my repro attempts are still timing-sensitive (failed on a user's browser, not in headless Chrome), so no stable repro to share yet. When the resolved-target navigation lands on npm I'll re-test the relative spelling and drop the workaround.

[ryansolid]

Root cause found and fixed in solidjs/solid-router#592.

Your instinct about the commit path was right, but the cancelable queueMicrotask itself wasn't the problem — the dedupe check in front of it was. In Solid 2, signal writes are transition forks that reads only observe once flushed, so effective() (the location read navigateFromRoute dedupes against) can lag the router's own actions by up to a flush. That opens two windows where a soft navigation is silently dropped as "already there":

1. A navigate() racing a pending target whose setNavigateTarget write hasn't flushed compares against the old location instead of the pending target — so a competing earlier target can win over the last call.
2. A navigate() issued right after the commit microtask runs navigateEnd — before the source write flushes — dedupes against the stale pre-commit location.

A redirect folded out of single-flight data triggers navigate() from exactly that kind of microtask context, which is why it was timing/environment sensitive; the absolute-URL form was reliable only because it takes the hard window.location.href path and never enters the soft-navigation dedupe.

The fix makes the dedupe compare against state that never lags: the pending transition target when one exists, and the just-committed target until the reactive read catches up (self-invalidating if a native pop supersedes it). A 200-round randomized burst stress test reproduced the drop deterministically before the fix and passes after.

Relative redirect('/') from an action will navigate reliably once that lands in the next router release.

[ryansolid]

Fixed in @solidjs/router 2.0.0-next.20 (solidjs/solid-router#592): navigation commitment was rebuilt on the signals transition engine — one canonical location source, engine last-write-wins for repeated navigate() calls, history written only after the winning transition settles. The commit-window dedupe race that dropped the relative-Location redirect no longer exists structurally. If you can still reproduce on next.20, please reopen.