Redirecting from server hook (with remote command) fails

[Tinggaard]

Describe the bug

If the hooks.server.ts redirects during the handle of a remote command, neither the redirect nor the body of the command gets executed, instead an error is shown that redirects cannot happen in remote commands.

I have setup in which the server hook will redirect if the users refresh token expires, which sometimes happens in between navigation, when the user presses a button to trigger a remote command.

It is of course possible to overcome this issue, by using a query function instead, but it is not ideal (or to me at least not described properly in the docs), that the limitations disallowing redirects in a command, also propagate to the server hook.

Essentially, having this auth-expiry kind of redirect in the server hook disallows any usage of remote command functions. Is it possible to overcome this somehow? Otherwise I would suggest to have the docs state this more clearly - that the disallowed redirects also account for the hook, not just the body of the remote command.

Reproduction

https://stackblitz.com/github/Tinggaard/remote-command-redirect-hook

In short terms:

src/hooks.server.ts

import { redirect, type Handle } from "@sveltejs/kit";

export const handle: Handle = async ({ event, resolve }) => {
  // some logic here that redirects if the users auth token is about to expire or the like
  // could happen when a remote request is invoked - hardcoded for the purpose of the demo
  if (event.isRemoteRequest)
    redirect(307, '/auth')

  return await resolve(event);
};

src/routes/cmd.remote.ts

import { command } from "$app/server";
import z from "zod";

export const foo = command(z.string(), (_) => {
  console.log('Command invoked!');
});

src/routes/+page.svelte

<script lang="ts">
  import { foo } from "./cmd.remote";
</script>

<svelte:boundary>
  <button onclick={async () => await foo("bar")}>trigger!</button>

  {#snippet pending()}
    loading...
  {/snippet}

  {#snippet failed(error, reset)}
    <pre>{error}</pre>

    <button onclick={reset}>Try again</button>
  {/snippet}
</svelte:boundary>

Invoking the remote command neither redirects nor executes the function body.

Logs

In the client console:

Uncaught (in promise) Error: Redirects are not allowed in commands. Return a result instead and use goto on the client

System Info

System:
    OS: Linux 6.17 Arch Linux
    CPU: (16) x64 AMD Ryzen 7 8845HS w/ Radeon 780M Graphics
    Memory: 21.57 GB / 27.15 GB
    Container: Yes
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.9.0 - /usr/bin/node
    npm: 11.6.1 - /usr/bin/npm
    pnpm: 10.18.0 - /usr/bin/pnpm
  Browsers:
    Brave Browser: 139.1.81.137
    Chromium: 141.0.7390.54
    Firefox: 143.0.4
    Firefox Developer Edition: 143.0.4
  npmPackages:
    @sveltejs/adapter-auto: ^6.1.0 => 6.1.1
    @sveltejs/kit: ^2.43.2 => 2.48.3
    @sveltejs/vite-plugin-svelte: ^6.2.0 => 6.2.1
    svelte: ^5.39.5 => 5.43.0
    vite: ^7.1.7 => 7.1.12

Severity

serious, but I can work around it

Additional Information

No response

[sillvva]

https://svelte.dev/docs/kit/remote-functions#Redirects

Inside query, form and prerender functions it is possible to use the redirect(...) function. It is not possible inside command functions, as you should avoid redirecting here. (If you absolutely have to, you can return a { redirect: location } object and deal with it in the client.)

In general, you should avoid doing redirects in hooks. Instead, set a user/session object on event.locals and handle the redirect at the remote/load function layer.

export const cmd = command(v.string(), () => {
  const event = getRequestEvent();
  if (!event.locals.user) return { redirect: '/login' }
});

Sveltekit recommends following the lucia guide for auth best practices. In their Sveltekit example, it shows what I mentioned here by using locals and redirecting in functions on a case-by-case basis. The BetterAuth docs also show only setting locals and does not redirect in the hooks.

If you want to create a wrapper function guardedCommand() to reduce boilerplate, you can use this video by Simon (dummdidumm) as a guide:
https://www.youtube.com/watch?v=z0f7NLPdLYE

Or you can use this sample I made that supports functions both with a schema and without: https://gist.github.com/sillvva/1cd1c04347fa66ecc402eb1764e6852b

[Tinggaard]

Thanks a lot for all the materials!

I do see the point of not redirecting from the hook, if only parts of the app are protected. However, in my case my entire app is protected by an auth guard, and only the /auth/* endpoints are actually allowed without any access token.
If I changed the setup I would be afraid to miss redirecting from some endpoint (especially when expanding both our developer team, but also the app size), leading to unauthenticated access to the app.

Given that this is "only" a best-practice / recommendation, I would still be happy to see the above behavior either mentioned explicitly somewhere in the docs, or changed.

[sillvva]

My app is the same. 2 unprotected pages, and the rest all protected. I use a custom eslint rule to enforce using guardedQuery over query and the same for the other remote functions. And then for unprotected functions, I disable the rule explicitly. eslint rules are really useful when working on teams to enforce organization rules and best practices.

export const getAll = guardedQuery(function* ({ user }) {
	const Characters = yield* CharacterService;
	return yield* Characters.get.all(user.id);
});

// eslint-disable-next-line custom/enforce-guarded-functions
export const get = query(
	v.object({
		param: characterIdParamSchema,
		newRedirect: v.optional(v.boolean(), false)
	}),
	(input) => ...

[sillvva]

As for whether to update the docs or change the rule, that's a decision the Svelte maintainers would have to make. You could submit a PR to update the docs if you want to get it started.

This is their Auth Best Practices page: https://svelte.dev/docs/kit/auth (Github)

[Conduitry]

Allowing redirect() inside a command() was something that I was actually thinking about several days ago, also in an authentication context. My thought was that, while we couldn't do client-side navigation this way (what would happen to the code that's currently awaiting the promise?), it did sound possible to trigger a hard navigation (by making the remote function promise never resold, and then triggering the navigation, unloading all of that code and avoiding a memory leak). I brought it up with other maintains, and there wasn't a lot of buy-in, but maybe if this is something that multiple other people want, that could move the needle.

[Rich-Harris]

#16328 (comment)