\n \u003C/HydrateClient>\n );\n};\n\nexport default Page;\n```\nAll is working on local development is perfect. But when I try to build it-\n\n```\nError occurred prerendering page \"/unavailability\". Read more: https://nextjs.org/docs/messages/prerender-error\nTRPCClientError: Unauthorized request. Please login\n at s.from (/vercel/path0/.next/server/chunks/949.js:3:83107)\n at /vercel/path0/.next/server/chunks/949.js:3:89907\n at process.processTicksAndRejections (node:internal/process/task_queues:105:5)\nExport encountered an error on /(dashboard)/unavailability/page: /unavailability, exiting the build.\n ⨯ Static worker exited with code: 1 and signal: null\n ELIFECYCLE Command failed with exit code 1.\nError: Command \"pnpm run build\" exited with 1\n\n```\n\n\nSo, it is natural that on build time, there is no authentications. But it stopping to build it-\n\n\n\n\n### Link to reproduction\n\nhttps://github.com/wegreet/dashboard-new-design\n\n### To reproduce\n\nJust build it with vercel\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!",[2914,2917],{"name":2915,"color":2916},"👻 invalid","e4e669",{"name":2918,"color":2919},"🐛 bug: unconfirmed","e99695",6441,"bug: TRPC with nextjs 15(App Router) production build failed!","2025-02-05T17:24:47Z","https://github.com/trpc/trpc/issues/6441",0.7057242,{"description":2926,"labels":2927,"number":2934,"owner":2868,"repository":2906,"state":2897,"title":2935,"updated_at":2936,"url":2937,"score":2938},"Hi,\r\n\r\nI am currently trying to use trpc open api on nextjs new app directory structure. (nextjs 13)\r\n\r\nThe issue is that request and response of the new [route handlers](https://beta.nextjs.org/docs/routing/route-handlers) are incompatible with with the core http/node you have.\r\n\r\nHere is the type of the request: https://beta.nextjs.org/docs/api-reference/request and the response: https://beta.nextjs.org/docs/api-reference/response\r\n\r\nHave you planned to handle this case too ?\r\n\r\nThanks a lot !",[2928,2931],{"name":2929,"color":2930},"enhancement","a2eeef",{"name":2932,"color":2933},"help wanted","008672",289,"Handle nextjs 13 App directory ","2023-10-29T18:06:39Z","https://github.com/trpc/trpc-openapi/issues/289",0.70891017,{"description":2940,"labels":2941,"number":2945,"owner":2868,"repository":2868,"state":2897,"title":2946,"updated_at":2947,"url":2948,"score":2949},"Some recommendations for improvements to the API:\r\n\r\n- I don't really see any reason to split up `@trpc/server` and `@trpc/client`. I think they should be merged into a single `trpc` module. It makes the out-of-the-box experience so much cleaner.\r\n- Then the `@trpc` scope can be used for specific plugins/adapters etc. You could publish the Express adapter as `@trpc/express` for instance. That would also let you properly specify all the requisite peerDependencies (which I don't believe are specified using the current `@trpc/server/adapters/express` approach since it doesn't have its own package.json.\r\n- I think `import * as` imports are a bad user experience. I submitted a PR with a solution.\r\n- Simplify the function names: `createTRPCClient` => `createClient`, `createNextApiHandler` => `createHandler`, `CreateNextContextOptions` => `ContextOptions`. It should be standard across adapters. It's obvious that a function called `createHandler` imported from `\"@trpc/server/adapters/next\"` is creating a Next.js API handler. It doesn't need to be in the name.\r\n- The adapters should export a `createContext` function that can automatically type `opts` with the necessary types.\r\n- I think all requests (queries and mutations) should get served from a single URL. The `path` can be added as an additional query parameter for queries and in the `body` for mutations. This would also simplify the Next/Express adapters (no need for a catchall API route).\r\n\r\n\r\nLess important:\r\n\r\nI think there should be a way of manually typing the input of a resolver without passing a validator into `input`. This is easy to do if the resolver functions had two parameters instead of one. I have this working on a local branch (type inference still works the same).\r\n\r\nI propose this syntax/convention:\r\n\r\n```ts\r\nconst router = trpc.router\u003CContext>().query('test', {\r\n resolve(input: number, req) {\r\n return input;\r\n },\r\n });\r\n```\r\n\r\nThe `req` variable above if of type `{ ctx: TContext, type: ProcedureType }`. This leaves the door open to future API expansion, as `req` can act like a catchall for any additional properties we want to pass into resolvers. ",[2942],{"name":2943,"color":2944},"💬 discussion","4B318A",211,"API recommendations","2021-04-12T21:57:33Z","https://github.com/trpc/trpc/issues/211",0.711061,{"description":2951,"labels":2952,"number":2953,"owner":2868,"repository":2868,"state":2897,"title":2954,"updated_at":2955,"url":2956,"score":2957},"### Provide environment information\n\n```\r\nSystem:\r\n OS: macOS 12.4\r\n CPU: (10) arm64 Apple M1 Pro\r\n Memory: 532.77 MB / 16.00 GB\r\n Shell: 5.8.1 - /bin/zsh\r\n Binaries:\r\n Node: 16.15.0 - /usr/local/bin/node\r\n Yarn: 1.22.19 - ~/.yarn/bin/yarn\r\n npm: 8.5.5 - /usr/local/bin/npm\r\n Browsers:\r\n Chrome: 104.0.5112.79\r\n Safari: 15.5\r\n npmPackages:\r\n @trpc/client: ^9.26.2 => 9.26.2 \r\n @trpc/next: ^9.26.2 => 9.26.2 \r\n @trpc/react: ^9.26.2 => 9.26.2 \r\n @trpc/server: ^9.26.2 => 9.26.2 \r\n next: 12.2.3 => 12.2.3 \r\n react: 18.2.0 => 18.2.0 \r\n react-query: 3.39.2 => 3.39.2 \r\n @sentry/nextjs: 7.9.0 => 7.9.0\r\n```\n\n### Describe the bug\n\nI've just been wrestling an integration detail between `tRPC`, `next.js` and `sentry`'s error monitoring sdk for next.js (`@sentry/nextjs`). I finally got to the bottom of it and wanted to post it to save some poor souls the hours. \r\n\r\nI don't know that this should be fixed. Maybe it could be added to some documentation as a recommendation for integrating these tools. Happy to make that PR and close this issue if ya'll agree.\r\n\r\nBasically I have tRPC implemented in my next.js app (used create-t3-app) and I'm adding sentry error monitoring. Sentry thankfully supplies an sdk for next.js to take care of the dual server/client nature of next.js and log exceptions thrown in both environments - `@sentry/nextjs`. \r\n\r\nHowever, it seems that errors thrown in a tRPC resolver function are **not** logged to sentry. I went down the rabbit hole with [this thread](https://github.com/getsentry/sentry-javascript/issues/3917) and a couple others before proving you can manually put a try/catch in the resolver function and log it as follows\r\n```\r\nexport const someRouter = createRouter().query('something', {\r\n async resolve() {\r\n try {\r\n // some error throwing code\r\n } catch (e) {\r\n Sentry.captureException(e)\r\n throw e\r\n }\r\n }\r\n})\r\n```\r\n_Note unless you are wrapping your tRPC router in `@sentry/nextjs`'s `withSentry` method (even through it fails to log the exceptions themselves) to ensure sentry gets initialized via your sentry.server.config.js config, you'll need to also Sentry.init({dsn: ...}) before you can capture the exception_\r\n\r\nThat resulted in 3 (or whatever your react-query retry threshold is set to) errors thrown for every error thrown in my tRPC query. \r\n\r\nThat's not what we want, but this led me to believe that tRPC's internal react-query implementation may be capturing any errors thrown so it can execute its retries before eventually sending the error to client side, so from sentry's perspective the errors are all \"handled\", and therefore do not get logged via the `withSentry` method.\r\n\r\nThe solution I ended up with seems reasonably clean. It ensures\r\n- tRPC errors are only thrown once all retries have failed\r\n- the error capturing code is in a centralised location, so no need to implement it on every query\r\n- no need to handroll sentry.init'ing\r\n\r\n```\r\n// src/pages/api/trpc/[trpc.ts]\r\nimport { createNextApiHandler } from '@trpc/server/adapters/next'\r\nimport { createContext } from 'server/router/context'\r\nimport { appRouter } from 'server/router'\r\nimport { withSentry, captureException } from '@sentry/nextjs'\r\n\r\nexport default withSentry(\r\n createNextApiHandler({\r\n router: appRouter,\r\n createContext: createContext,\r\n onError({ error }) {\r\n if (error.code === 'INTERNAL_SERVER_ERROR') {\r\n captureException(error)\r\n }\r\n }\r\n })\r\n)\r\n```\r\n\r\n\n\n### To reproduce\n\n- create a new app via [create-t3-app](https://github.com/t3-oss/create-t3-app)\r\n- integrate sentry following [this guide](https://docs.sentry.io/platforms/javascript/guides/nextjs/)\r\n- throw an error in the example api query\r\n- confirm the log never arrives in your sentry issues tab\r\n\n\n### Additional information\n\n_No response_\n\n### 👨👧👦 Contributing\n\n- [X] 🙋♂️ Yes, I'd be down to file a PR fixing this bug!",[],2414,"bug: tRPC in a next.js app swallows errors such that @sentry/nextjs cannot log server errors","2022-08-17T00:00:48Z","https://github.com/trpc/trpc/issues/2414",0.71152073,{"description":2959,"labels":2960,"number":2961,"owner":2868,"repository":2906,"state":2897,"title":2962,"updated_at":2963,"url":2964,"score":2965},"Hey Guys\r\n\r\nI've started using the T3 Stack with trpc / nextjs and wanted to use this awesome package to my Project.\r\nEverything works fine and I see the OpenAPI-Docs in the expected route. But i dont understand why this happens\r\n\r\nWhen looking at my trpc query, I have the following:\r\n```ts\r\nexport const exampleRouter = createRouter().query(\"hello\", {\r\n meta: { openapi: { enabled: true, method: \"GET\", path: \"/api/trpc/example.hello\" } },\r\n input: z.object({ name: z.string() }),\r\n output: z.object({ greeting: z.string() }),\r\n resolve: ({ input }) => {\r\n return { greeting: `Hello ${input.name}!` };\r\n },\r\n});\r\n```\r\nwhich generated the OpenAPI docs but when i try to execute it throught the UI it generates the URL like this:\r\n`http://0.0.0.0:3000/api/trpc/example.hello?name=asdf` which is of course not wrong. But when looking into the dev-tools on my page the request generated from trpc-client is generated like this:\r\n`http://localhost:3000/api/trpc/example.hello?batch=1&input={\"0\":{\"json\":{\"name\":\"jerome\"}}}`\r\n\r\nCan i change this behavior for the generation of the OpenAPI docs or how would you recommend trying to fix this?\r\n\r\nThanks in advanced\r\nJerome",[],149,"[Help wanted] T3 Stack and Queryparameters","2023-06-08T11:28:37Z","https://github.com/trpc/trpc-openapi/issues/149",0.7203618,["Reactive",2967],{},["Set"],["ShallowReactive",2970],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fU_SfEFhhTMn4iomAK-urV2IVE1RqvBpOMm4Rjk21pPE":-1},"/trpc/trpc-openapi/424"]