\n\n\n\n### Link to reproduction\n\nNot Needed\n\n### To reproduce\n\nfetch an query on the server and the error type is messed up\n\n### Additional information\n\n_No response_\n\n### 👨👧👦 Contributing\n\n- [ ] 🙋♂️ Yes, I'd be down to file a PR fixing this bug!",[3216],{"name":3217,"color":3218},"🐛 bug: unconfirmed","e99695",6956,"bug: since TRPC v11.5.0 errors on createTRPCOptionsProxy are broken and not typed properly","2025-09-22T23:38:43Z","https://github.com/trpc/trpc/issues/6956",0.6911396,{"description":3225,"labels":3226,"number":3227,"owner":3172,"repository":3182,"state":3228,"title":3229,"updated_at":3230,"url":3231,"score":3232},"I have set up two routes in order to see how trpc-openapi generated error responses in the spec file, but I can't seem to get it to work.\r\n\r\nHere is the resulting spec:\r\n```yaml\r\n/error/bad-request:\r\n get:\r\n operationId: query.error.badRequest\r\n parameters: []\r\n responses:\r\n '200':\r\n description: Successful response\r\n content:\r\n application/json:\r\n schema: {}\r\n default:\r\n $ref: '#/components/responses/error'\r\n /error/too-many-requests:\r\n get:\r\n operationId: query.error.tooManyRequests\r\n parameters: []\r\n responses:\r\n '200':\r\n description: Successful response\r\n content:\r\n application/json:\r\n schema: {}\r\n default:\r\n $ref: '#/components/responses/error'\r\n```\r\n\r\nAnd here is the TypeScript definition:\r\n\r\n```ts\r\nimport { z } from \"zod\";\r\n\r\nimport { createTRPCRouter, publicProcedure } from \"../trpc\";\r\nimport { TRPCError } from \"@trpc/server\";\r\n\r\nexport const errorRouter = createTRPCRouter({\r\n badRequest: publicProcedure\r\n .meta({\r\n openapi: {\r\n method: \"GET\",\r\n path: \"/error/bad-request\",\r\n },\r\n })\r\n .input(z.void())\r\n .output(z.void())\r\n .query(() => {\r\n throw new TRPCError({\r\n code: \"BAD_REQUEST\",\r\n message: \"Bad request\",\r\n });\r\n }),\r\n tooManyRequests: publicProcedure\r\n .meta({\r\n openapi: {\r\n method: \"GET\",\r\n path: \"/error/too-many-requests\",\r\n },\r\n })\r\n .input(z.void())\r\n .output(z.void())\r\n .query(() => {\r\n throw new TRPCError({\r\n code: \"TOO_MANY_REQUESTS\",\r\n message: \"Too many requests\",\r\n });\r\n }),\r\n});\r\n```\r\n\r\nUsing cURL on the REST endpoints, I can see that the proper response codes are returned, but I don't understand why that doesn't show up in the spec. Is that intended behaviour, or do I need to do something different?",[],258,"closed","Next.js adapter doesn't generate error status codes in openapi.json","2023-03-03T11:02:30Z","https://github.com/trpc/trpc-openapi/issues/258",0.6525112,{"description":3234,"labels":3235,"number":3239,"owner":3172,"repository":3172,"state":3228,"title":3240,"updated_at":3241,"url":3242,"score":3243},"Hi there,\r\n\r\nfirst of all: Thanks a lot for creating trpc :) I just recently stumpled upon it and I'm quite enthusiastic about it's design.\r\n\r\nNow to the problem:\r\n\r\nI'm trying to use trpc in a pnpm-driven monorepo. When I try to compile the package that's using trpc (both `@trpc/server` and `@trpc/client`), `tsc` fails with:\r\n\r\n```\r\n../../../../node_modules/.pnpm/@trpc+server@9.23.4/node_modules/@trpc/server/dist/declarations/src/adapters/node-http/types.d.ts:3:16 - error TS2307: Cannot find module 'qs' or its corresponding type declarations.\r\n\r\n3 import qs from 'qs';\r\n\r\n[...]\r\n\r\n../../../../node_modules/.pnpm/@trpc+server@9.23.4/node_modules/@trpc/server/dist/declarations/src/adapters/standalone.d.ts:5:107 - error TS2344: Type 'IncomingMessage' does not satisfy the constraint 'NodeHTTPRequest'.\r\n Type 'IncomingMessage' is not assignable to type '{ method?: string; query?: any; body?: unknown; }' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.\r\n Types of property 'method' are incompatible.\r\n Type 'string | undefined' is not assignable to type 'string'.\r\n Type 'undefined' is not assignable to type 'string'.\r\n\r\n5 export declare type CreateHTTPHandlerOptions\u003CTRouter extends AnyRouter> = NodeHTTPHandlerOptions\u003CTRouter, http.IncomingMessage, http.ServerResponse>;\r\n```\r\n\r\nThe first one\r\n```\r\nTS2307: Cannot find module 'qs' or its corresponding type declarations.\r\n```\r\n\r\ncan be fixed by installing `@types/qs`. However, I don't think that should be necessary.\r\n\r\nThe second one\r\n```\r\nTS2344: Type 'IncomingMessage' does not satisfy the constraint 'NodeHTTPRequest'.\r\n```\r\nisn't explicable to me but at least resembles one of the errors documented in #1022.\r\n\r\nThis issue was closed by #1151, which should be included with the trpc version I'm using (9.23.4).\r\n\r\nIt's possible that this is related to my use of pnpm.\r\n\r\nAny hint would be appreciated :) I'll keep you posted, if I find anything myself.",[3236],{"name":3237,"color":3238},"🐛 bug","d73a4a",1904,"Type Errors","2022-10-04T12:02:52Z","https://github.com/trpc/trpc/issues/1904",0.66753834,{"description":3245,"labels":3246,"number":3247,"owner":3172,"repository":3172,"state":3228,"title":3248,"updated_at":3249,"url":3250,"score":3251},"Hello 👋 First of all thank you so much for this amazing project, it's _awesome_ to use and we're adopting it for some of our public facing services as an alternative to GraphQL at utility-company scale\r\n\r\nQuestion about error handling best practices; the JSON-RPC spec includes the following description:\r\n\r\n> The error codes from and including -32768 to -32000 are reserved for pre-defined errors. Any code within this range, but not defined explicitly below is reserved for future use. The error codes are nearly the same as those suggested for XML-RPC at the following url: http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php\r\n\r\n> The remainder of the space is available for application defined errors.\r\n\r\nhttps://www.jsonrpc.org/specification#error_object\r\n\r\nHowever, TRPC errors appear limited to the subset defined in the spec:\r\n\r\n\r\n\r\nDoes this mean that best practices for error handling is to return them as a standard result of the request instead of as a special error thrown:\r\n\r\n```typescript\r\n// I.e. this\r\nreturn { error: \"CUSTOM_ERROR\" }; // This would also now be typed correctly on the client\r\n// Instead of this\r\nthrow new TRPCError({ code: \"CUSTOM_ERROR\" }); // This is a type error\r\n```\r\n\r\nOnce again, thank you so much for this amazing library!",[],631,"Error handling best practices","2022-10-05T00:09:30Z","https://github.com/trpc/trpc/issues/631",0.6744929,{"description":3253,"labels":3254,"number":3264,"owner":3172,"repository":3172,"state":3228,"title":3265,"updated_at":3266,"url":3267,"score":3268},"While working on a project with tRPC (based on the `fastify-server` example), I came across a type error while attempting to build the project.\r\n```\r\nnode_modules/@trpc/client/dist/declarations/src/TRPCClientError.d.ts:13:14 - error TS2416: Property 'cause' in type 'TRPCClientError\u003CTRouter>' is not assignable to the same property in base type 'Error'.\r\n Type 'Maybe\u003CError>' is not assignable to type 'Error | undefined'.\r\n Type 'null' is not assignable to type 'Error | undefined'.\r\n\r\n13 readonly cause: Maybe\u003CError>;\r\n ~~~~~\r\n\r\nnode_modules/@trpc/server/dist/declarations/src/TRPCError.d.ts:7:14 - error TS2416: Property 'cause' in type 'TRPCError' is not assignable to the same property in base type 'Error'.\r\n Type 'unknown' is not assignable to type 'Error | undefined'.\r\n\r\n7 readonly cause?: unknown;\r\n ~~~~~\r\n``` \r\n \r\nI managed to figure out what causes the bug: There is a breaking change in `typescript@4.6.2`, [this one](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-6.html#object-rests-drop-unspreadable-members-from-generic-objects) I believe \r\nThrough more testing, I also figured out a few workarounds: \r\n- Use `typescript@4.5.5`\r\n- Set the `target` in `tsconfig.json` to `ES2021`\r\n- Set the `target` in `tsconfig.json` to `ES6` \r\n \r\nI was going to file a PR, but then I wasn't sure exactly what needs to be fixed(?). Is this a bug that needs fixing within tRPC itself? Should there be a warning in the docs? Should the examples use the aforementioned `tsconfig` workaround? Should the entire repo use the `tsconfig` workaround? \r\n \r\nI am very willing to help with a fix but I need some insight. ",[3255,3258,3261],{"name":3256,"color":3257},"@trpc/server","9BE78E",{"name":3259,"color":3260},"@trpc/client","6095C2",{"name":3262,"color":3263},"🔎 needs more investigation/info","d4c5f9",2292,"Potential for future type error in TRPCError & TRPCClientError","2022-09-29T21:24:11Z","https://github.com/trpc/trpc/issues/2292",0.6757486,{"description":3270,"labels":3271,"number":3272,"owner":3172,"repository":3172,"state":3228,"title":3273,"updated_at":3274,"url":3275,"score":3276},"Hi there ! thanks for the awesome lib !\r\n\r\nI have lost a bit of time the past couple of day so I'd figured I would share my story and my resolutions for the record.\r\n\r\nI have been deploying my trpc router in express in a serverless context, specifiically with `@vendia/serverless-express`. something like:\r\n\r\n```ts\r\n\r\nconst express = require(\"express\");\r\nimport * as trpcExpress from \"@trpc/server/adapters/express\";\r\nimport serverlessExpress from \"@vendia/serverless-express\";\r\nimport { router, inferAsyncReturnType } from \"@trpc/server\";\r\nimport { CreateExpressContextOptions } from \"@trpc/server/adapters/express\";\r\n\r\n// trpc router\r\nexport const createContext = ({\r\n req,\r\n res,\r\n}: CreateExpressContextOptions) => ({}); // no context\r\n\r\nexport type Context = inferAsyncReturnType\u003Ctypeof createContext>;\r\n\r\n// simplest router ever\r\nexport const appRouter = router\u003CContext>()\r\n .mutation(\"hello-mut\", {\r\n input: z.object({\r\n id: z.string(),\r\n }),\r\n resolve({ input }) {\r\n return { id: input.id };\r\n },\r\n });\r\n\r\nconst app = express();\r\n\r\napp.use(\r\n \"/trpc\",\r\n trpcExpress.createExpressMiddleware({\r\n router: appRouter,\r\n createContext: createContext,\r\n })\r\n);\r\n\r\nexport const handler = serverlessExpress({ app });\r\n\r\n```\r\n\r\nLocally when running project through the default express listener, everything is fine. but as I soon as I would deploy even the simplest of mutation in aws lambdas, I would get this error:\r\n\r\n```json\r\n[\r\n {\r\n \"id\":null,\r\n \"error\":{\r\n \"message\":\"[\\n {\\n \\\"code\\\": \\\"invalid_type\\\",\\n \\\"expected\\\": \\\"object\\\",\\n \\\"received\\\": \\\"number\\\",\\n \\\"path\\\": [],\\n \\\"message\\\": \\\"Expected object, received number\\\"\\n }\\n]\",\r\n \"code\":-32600,\r\n \"data\":{\r\n \"code\":\"BAD_REQUEST\",\r\n \"httpStatus\":400,\r\n \"stack\":\"TRPCError: [\\n {\\n \\\"code\\\": \\\"invalid_type\\\",\\n \\\"expected\\\": \\\"object\\\",\\n \\\"received\\\": \\\"number\\\",\\n \\\"path\\\": [],\\n \\\"message\\\": \\\"Expected object, received number\\\"\\n }\\n]\\n at Procedure.parseInput (/Users/tclain/z/p/apex/.sst/artifacts/dev-apex-api-nexus-core-api-Lambda_default/src/api/index.js:2881:17)\\n at processTicksAndRejections (node:internal/process/task_queues:96:5)\\n at async /Users/tclain/z/p/apex/.sst/artifacts/dev-apex-api-nexus-core-api-Lambda_default/src/api/index.js:2891:25\\n ..... REST of call stack......\",\r\n \"path\":\"hello-mut\"\r\n }\r\n }\r\n }\r\n]\r\n```\r\n\r\nWait what 😱 ??\r\ni Have no number at all in my mutation but the error says it is received a number. When debugging this number was \"123\".\r\n\r\nSo I went into the rabbit hole and it turns out that the serverless handler parses `req.body` as a.... Buffer, not a string and it seems trpc expect a string.\r\n\r\nSo in `resolveHTTPResponse` instead of receiving:\r\n\r\n```\r\n{ [batchId]: JSON payload\r\n}\r\n```\r\n\r\nit receives:\r\n\r\n```\r\nSerialized Buffer\r\n```\r\n\r\nwith console logs in this file:\r\n```\r\nDEV bodyResult {\"0\":{\"id\":\"bla\"}}\r\nDEV - getInputs {\r\n '0': 123,\r\n '1': 34,\r\n '2': 48,\r\n '3': 34,\r\n '4': 58,\r\n '5': 123,\r\n '6': 34,\r\n '7': 105,\r\n '8': 100,\r\n '9': 34,\r\n '10': 58,\r\n '11': 34,\r\n '12': 98,\r\n '13': 108,\r\n '14': 97,\r\n '15': 34,\r\n '16': 125,\r\n '17': 125,\r\n readBigUInt64LE: [Function: readBigUInt64LE],\r\n readBigUInt64BE: [Function: readBigUInt64BE],\r\n readBigUint64LE: [Function: readBigUInt64LE],\r\n readBigUint64BE: [Function: readBigUInt64BE],\r\n readBigInt64LE: [Function: readBigInt64LE],\r\n readBigInt64BE: [Function: readBigInt64BE],\r\n writeBigUInt64LE: [Function: writeBigUInt64LE],\r\n writeBigUInt64BE: [Function: writeBigUInt64BE],\r\n ...... REST OF Buffer object,\r\n swap64: [Function: swap64],\r\n toLocaleString: [Function: toString]\r\n}\r\nDEV - getInput for each 123\r\nDEV number 123\r\nDEV t [ZodError]: [\r\n {\r\n \"code\": \"invalid_type\",\r\n \"expected\": \"object\",\r\n \"received\": \"number\",\r\n \"path\": [],\r\n \"message\": \"Expected object, received number\"\r\n }\r\n]\r\n```\r\nand so the batch \"0\" get the first value of the array like Buffer, here the number 123....\r\n\r\n\r\nSo at this point I was puzzled.\r\n\r\nWhat I have done right now to make it work is to create a small middleware that detects if the body is a buffer and replace it with the string version:\r\n\r\n```ts\r\napp.use((req, res, next) => {\r\n if (req.body && Buffer.isBuffer(req.body)) {\r\n req.body = req.body.toString();\r\n }\r\n next();\r\n});\r\n```\r\n\r\nHope that helps someone else... Would it be sensible to handle that in trpc ? I have noticed that the recommended approach is \"plug and play\" and it should just work ™️, so I guess this additional check could help.\r\n\r\n\r\n\r\n",[],1550,"Mutation fails when using express adapter in serverless scenario (request body is a buffer)","2022-02-22T14:35:07Z","https://github.com/trpc/trpc/issues/1550",0.67875195,["Reactive",3278],{},["Set"],["ShallowReactive",3281],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fFQ_le2Ajsxxc1A0XBPDQp7UcfTbYmKGfiM8C8-BaBWw":-1},"/trpc/trpc-openapi/440"]