Vercel ISR strips `payload` query parameter from remote function endpoints on rest parameter routes

[arichardsmith]

Describe the bug

Remote functions fail on Vercel production deployments when a rest parameter route (e.g., /[...rest]) is configured with ISR (Incremental Static Regeneration) settings. The payload query parameter used to pass arguments to remote functions is stripped out by Vercel's ISR implementation, causing the validation to fail.

Remote functions create endpoints at the route /_app/remote/[id]/[function]?payload={encoded arguments}. When a rest parameter route (i.e., /[...rest]) matches all routes, the function built to handle this route also handles remote function calls.

When ISR is configured for that route, Vercel strips out any query parameters that aren't explicitly allowed in the configuration—which includes the payload parameter used to pass remote function arguments.

Reproduction

I've got a minimal reproduction here: github.com/arichardsmith/sveltekit-vercel-remote-bug and a deployment is available on Vercel to poke at.

In short:

• Create a rest parameter route at the root level (i.e. routes/[...rest])
• Set the ISR config in routes/[...rest]/+page.server.ts
• Try to call a remote function with parameters from any page in the app

Logs

This is the error on the server, even though I'm passing the arguments.

Remote function schema validation failed: [
  {
    expected: 'array',
    code: 'invalid_type',
    path: [],
    message: 'Invalid input: expected array, received undefined'
  }
]

System Info

System:
    OS: macOS 15.6.1
    CPU: (8) arm64 Apple M1
    Memory: 78.83 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.11.1 - /nix/store/h57ln4r40qr349z1r8ri90n9i9xid3r5-nodejs-24.11.1/bin/node
    npm: 11.6.2 - /nix/store/h57ln4r40qr349z1r8ri90n9i9xid3r5-nodejs-24.11.1/bin/npm
    pnpm: 10.25.0 - /nix/store/nxr10pnynlzqsfcnc4h4zv2724a8i7v8-pnpm-10.25.0/bin/pnpm
  Browsers:
    Chrome: 143.0.7499.147
    Firefox: 145.0.1
    Safari: 18.6
  npmPackages:
    @sveltejs/adapter-vercel: ^6.2.0 => 6.2.0
    @sveltejs/kit: ^2.49.1 => 2.49.2
    @sveltejs/vite-plugin-svelte: ^6.2.1 => 6.2.1
    svelte: ^5.45.6 => 5.46.0
    vite: ^7.2.6 => 7.3.0

Severity

serious, but I can work around it

(It is particularly nasty as it only shows up when deployed)

Additional Information

This can be worked around by explicitly allowing payload query parameters in the ISR config:

export const config = {
	isr: {
		expiration: 60,
		allowQuery: ['payload']
	}
};

An easy fix would be for adapter-vercel to automatically add payload to the allowQuery, as is currently the case with __pathname. However, this would mean payload should be a reserved parameter, like __pathname is, which I guess would technically be a breaking change?

I'd be happy to file a PR if automatically adding the parameter (if there are remote functions in the app) is the preferred solution.

That said, using the rest parameter route handler for remote functions could cause issues down the road. Is there a reason remote functions aren't split into separate Vercel functions during the build?

---

Sorry for bringing Scrooge vibes filing an issue over Christmas, hopefully gift wrapping it with a repro helps take the edge off. Happy holidays and there's nothing wrong with this sitting unaddressed until after the holidays.

[elliott-with-the-longest-name-on-github]

I don't think your remote functions should ever be served by an ISR route like this -- the bug is just that [...rest] is capturing the remote requests. It should not be. Given that this only shows up in production I have a suspicion that the bug is actually just that the Build Output we emit has an incorrect routing table.

[arichardsmith]

You are right about the routing table, the first match for /_app/remote/* in .vercel/output/config.json would be the ^(/[^]*)?/?$ regex.

{
	"version": 3,
	"routes": [
		{
			"src": "/_app/immutable/.+",
			"headers": {
				"cache-control": "public, immutable, max-age=31536000"
			}
		},
		{
			"handle": "filesystem"
		},
		{
			"src": "^/clock/?(?:/__data.json)?$",
			"dest": "/clock"
		},
		{
			"src": "^(/[^]*)?/?$",
			"dest": "/[...op]?__pathname=/$1"
		},
		{
			"src": "^(/[^]*)?/?/__data.json$",
			"dest": "/[...op]/__data.json?__pathname=/$1"
		},
		{
			"src": "/.*",
			"dest": "/![-]/catchall"
		}
	],
	"overrides": {}
}

I also realised that just passing through the payload parameter isn't a good solution as the response is still cached, leading to some unexpected responses to queries. I've added a clock route to the repro to show this. You'll see the server time only update every 20 seconds (the ISR timeout).

This also shows that this leads to some pretty unexpected behaviour with the ISR config affecting remote functions called in completely unrelated routes.

The catchall route handler (at /![-]/catchall) does have the remote functions, would this be the intended handler for remote function requests? If so, patching the adapter to output a specific entry for remote function paths works for me (I can't share a live link as Vercel only lets me share one preview link!).

{
	"version": 3,
	"routes": [
+		{
+			"src": "/_app/remote/.+",
+			"dest": "/![-]/catchall"
+		},
		{
			"src": "/_app/immutable/.+",
			"headers": {
				"cache-control": "public, immutable, max-age=31536000"
			}
		},
		{
			"handle": "filesystem"
		},
		{
			"src": "^/clock/?(?:/__data.json)?$",
			"dest": "/clock"
		},
		{
			"src": "^(/[^]*)?/?$",
			"dest": "/[...op]?__pathname=/$1"
		},
		{
			"src": "^(/[^]*)?/?/__data.json$",
			"dest": "/[...op]/__data.json?__pathname=/$1"
		},
		{
			"src": "/.*",
			"dest": "/![-]/catchall"
		}
	],
	"overrides": {}
}

[elliott-with-the-longest-name-on-github]

Yeah, I think this is the right solution -- though we should probably check to make sure we don't need to do any additional symlinking of the remote routes to make Vercel analytics display useful paths 🤔

[arichardsmith]

I completely missed that the function folders were symlinked! Without the symlink it was showing as /![-]/catchall in observability.

I've tweaked the adapter to symlink /_app/remote to the catchall function and it shows up nicer in observability.

I figured this path made sense as it's what people will see in network request. We could make a symlink for every remote function, but I wonder if that would get excessive? I assume Observability pro users will still be able to see the different requested paths.

Should I open a PR for the adapter fix? The questions I have about my test implementation are:

• Is it ok to make /_app/remote the most important match? It comes before prerendered routes, but I think that's a good thing.
• What's the best route to show in Observability?
• I imagine we only want to add the route table entry if remote functions are enabled, but what about if there are no ISR routes? Would it still make sense to output the symlinks and route table entry?

[elliott-with-the-longest-name-on-github]

I think the correct resolution is this:

• Symlink /_app/remote to the catchall function (as you've done)
• We would still want to output the symlink if there are no ISR functions -- otherwise remote functions will look like they're going through the /![-] catchall route
• Ideally we'd only create this symlink and the associated routing entry if remote functions are enabled (and ideally only if there are remote functions, though I'm not sure that's possible right now)
• The routing table entry directing /_app/remote/* to the /_app/remote symlink route should occur after the handle: "filesystem" entry so that prerendered assets and filesystem matches take precedence
  • The way the routing table works is kind of bonkers, but basically those handle: "*" directives say "everything after this in the array applies after this phase"
  • I think this means we'd want to push it to the static config here, prior to emitting ISR and regular routes:

    kit/packages/adapter-vercel/index.js

    Lines 380 to 382 in 134ce49

    	}
    	for (const route of builder.routes) {

Feel free to open a PR when you get a chance, I'll review it ASAP!

[arichardsmith]

I've opened a PR here: #15098

I ended up putting it in an if block checking builder.config.kit.experimental.remoteFunctions. I couldn't see any way to check if the app actually has remote functions without building the manifest file and parsing it!

There's a builder.hasServerInstrumentationFile function for checking instrumentation, so I wonder if something like builder.hasRemoteFunctions should be added to the kit builder? The builder does know if there are remote functions, but the info doesn't seem to be exposed anywhere.

But, I figure that's beyond the initial adapter change!