[Tanstack-Query] queryOptionstype definitions allow passing procedure inputs at the top level, leading to silent failures

[jlucaso1]

Environment

"@orpc/client": "^1.8.5"
"@orpc/server": "^1.8.5"
"@orpc/tanstack-query": "^1.8.5"

Node 22

Reproduction

const listUsersInputSchema = z.object({
  page: z.number().optional().default(1),
  query: z.string().optional().default(''),
});

export const usersRouter = {
  list: publicProcedure
    .input(listUsersInputSchema)
    .handler(async ({ input }) => {
      // Logic to fetch users based on input.page and input.query
      console.log('Fetching with input:', input);
      return { users: [], total: 0 };
    }),
};

import { useQuery } from '@tanstack/react-query';
import { rpc } from './rpc-client';

function UserTable() {
  const activeQuery = 'some-search-term';

  // ❌ This code is functionally WRONG, but TypeScript thinks it's OK.
  // The `page` and `query` props are silently ignored.
  const { data, isLoading } = useQuery(
    rpc.users.list.queryOptions({
      query: activeQuery,
      // The `input` key is missing!
    })
  );
}

// ✅ This is the correct way to call it.
const { data, isLoading } = useQuery(
  rpc.users.list.queryOptions({
    input: { // Correctly nested
      query: activeQuery,
    },
  })
);

Describe the bug

It's easy for a developer to accidentally pass a procedure's input arguments at the top level of the queryOptions object, instead of nesting them under the input key.
When this happens, TypeScript doesn't raise any errors. The query still runs, but it silently ignores the inputs, leading to incorrect behavior (in my case, a search filter not working)

Additional context

No response

Logs

[dosubot]

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

This happens because the type definitions for queryOptions in @orpc/tanstack-query are permissive: they require the input to be nested under the input key, but they don't prevent you from adding extra top-level properties. TypeScript's intersection types don't enforce "exact object" shapes, so if you pass { query: ... } instead of { input: { query: ... } }, TypeScript doesn't complain—those extra properties are just ignored at runtime, leading to silent failures like you described. This is a known limitation of the current API design and TypeScript's type system, not something enforced by the library or its types [source].

There are no built-in safeguards or stricter type checks in the latest releases to prevent this mistake [source]. The best practice is to always nest your procedure inputs under the input key when using queryOptions. If you want to enforce this more strictly, you could add a custom linter rule or a wrapper utility in your codebase to catch accidental top-level input properties.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[dinwwwh]

Another requirement for this is that input can be optional or undefined.

(your repro is missing that)

This limitation comes from its own design when it tries to correctly reflect what you provide and what the result of .queryOptions is, and support all tanstack query library.

Even that, I still not thing this is a big deal ~~ it's more like skill issue