Can't call mutationOptions({}) from a context in Solidjs (SolidStart). In vercel deployment.

[renatonmag]

"@orpc/client": "^1.13.5", "@orpc/server": "^1.13.5"
I have this code here:

import { useMutation } from "@tanstack/solid-query";
import { orpc } from "~/lib/orpc";

export function useUpdateComponent() {
  const updateComponent = useMutation(() =>
    orpc.component.update.mutationOptions({}),
  );

  return updateComponent;
}

export const _StoreContext = createContext<IStoreContext>();
export const StoreContext = (props: any) => {
  const fns = useUpdateComponent();
  const store = createApplicationStore();
  return (
    <_StoreContext.Provider value={store}>
      {props.children}
    </_StoreContext.Provider>
  );
};

I don't use fns for nothing but the call to mutationOptions({}) blocks the page load in vercel deployment.
StoreContext is inside a QueryClientProvider.
Not sure what is the problem here, but I can't call mutationOptions({}) inside a context. This problem does not occur in local development only in the vercel deployment. I'm using solidstart

Thanks!

[dosubot]

Hi @renatonmag! I'm Dosu and I’m helping the orpc team.

This looks like a known issue with header forwarding in Vercel deployments. There's a confirmed bug where forwarding all incoming headers (especially content-length and content-encoding) causes fetch failed errors and blocking behavior in serverless environments.

Most likely fix: Check your oRPC link configuration and only forward safe headers:

const SAFE_HEADERS = [
  'cookie', 'authorization', 'x-forwarded-for', 'x-forwarded-host',
  'x-forwarded-proto', 'user-agent', 'referer', 'accept-language',
];

Additional recommendations:

1. Use the optimized SSR pattern from the SolidStart docs that separates server/client code to avoid making HTTP requests during SSR:

// Check if running on server
if (typeof window === 'undefined') {
  await import('./orpc.server')
}

export const client: RouterClient<typeof router> = globalThis.$client ?? createORPCClient(link)

2. Ensure proper link configuration using getRequestEvent() for SSR context, as shown in the SolidStart playground:

import { getRequestEvent } from 'solid-js/web'

const link = new RPCLink({
  url: `${typeof window !== 'undefined' ? window.location.origin : 'http://localhost:3000'}/rpc`,
  headers: () => getRequestEvent()?.request.headers ?? {},
})

Could you share your oRPC link/client configuration? That would help narrow down whether the header forwarding is the culprit.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[renatonmag]

This is my link and client

if (import.meta.env.SSR) {
    await import('./orpc.server')
}
    
import type { RouterClient } from '@orpc/server'
import type { router } from '~/routers'
import { createORPCClient } from '@orpc/client'
import { RPCLink } from '@orpc/client/fetch'
import { createTanstackQueryUtils } from '@orpc/tanstack-query'
import { getRequestEvent } from 'solid-js/web'
import { BatchLinkPlugin } from '@orpc/client/plugins'
  
declare global {
  var $client: RouterClient<typeof router> | undefined
}
  
const link = new RPCLink({
  url: `${typeof window !== 'undefined' ? window.location.origin : 'http://localhost:3000'}/rpc`,
  headers: () => getRequestEvent()?.request.headers ?? {},
  fetch: (input, init) => fetch(input, { ...init, credentials: 'include' }),
  plugins: [
    new BatchLinkPlugin({
      exclude: ({ path }) => path[0] === 'sse',
      groups: [{
        condition: () => true,
        context: {},
      }],
    }),
  ],
})

export const client: RouterClient<typeof router> = globalThis.$client ?? createORPCClient(link)

export const orpc = createTanstackQueryUtils(client)

[dosubot]

Found it! The issue is this line:

headers: () => getRequestEvent()?.request.headers ?? {},

You're forwarding all incoming request headers, including content-length and content-encoding. In Vercel's serverless environment, this causes a mismatch that blocks the request — it's a known issue.

Fix: Only forward safe headers:

const SAFE_HEADERS = [
  'cookie', 'authorization', 'x-forwarded-for', 'x-forwarded-host',
  'x-forwarded-proto', 'user-agent', 'referer', 'accept-language',
];

const link = new RPCLink({
  url: `${typeof window !== 'undefined' ? window.location.origin : 'http://localhost:3000'}/rpc`,
  headers: () => {
    const requestHeaders = getRequestEvent()?.request.headers;
    if (!requestHeaders) return {};
    
    const safeHeaders: Record<string, string> = {};
    for (const key of SAFE_HEADERS) {
      const value = requestHeaders.get(key);
      if (value) safeHeaders[key] = value;
    }
    return safeHeaders;
  },
  fetch: (input, init) => fetch(input, { ...init, credentials: 'include' }),
  plugins: [
    new BatchLinkPlugin({
      exclude: ({ path }) => path[0] === 'sse',
      groups: [{
        condition: () => true,
        context: {},
      }],
    }),
  ],
})

This should resolve the blocking issue in your Vercel deployment.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[renatonmag]

@dosu This is not the problem. What is happening is when I place the mutationOptions inside de context the first page does not even load. When I remove the useMutation(() =>orpc.component.update.mutationOptions({})); from the context the first page loads

[dosubot]

Thanks for clarifying! You're right, mutationOptions() itself doesn't make network requests — it's purely synchronous. So the issue is likely one of these two causes:

1. Server-only code leaking into the client bundle — This is the most common cause of SSR blocking in production. If your ~/lib/orpc file (or anything it imports) pulls in server-only modules, it can hang during SSR. This often only manifests in production due to different bundle optimization.

2. Stale globalThis.$client reference — The globalThis pattern captures the client at module initialization. If globalThis.$client isn't set yet when your context provider initializes, it falls back to createORPCClient(link), which then tries to use getRequestEvent(). In Vercel's serverless environment, this can behave differently than local dev.

Quick test: Try moving the useMutation call out of the context provider and into the component that actually uses it. If that works, the issue is initialization timing.

Debugging suggestions:

1. Check your Vercel function logs — do you see any errors or warnings?
2. Does your ~/lib/orpc (or ~/routers) import any server-only code that might be bundled into the client?
3. Try wrapping the mutation in a client-only check:

import { isServer } from 'solid-js/web'

export function useUpdateComponent() {
  const updateComponent = useMutation(() => 
    isServer ? { mutationKey: ['noop'], mutationFn: async () => {} } : orpc.component.update.mutationOptions({})
  );
  return updateComponent;
}

This would help confirm if the issue is specifically the mutation initializing during SSR.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[dinwwwh]

Have you tried it with pure TQ (without oRPC) yet? Issues like this are usually not related to oRPC.