feat: errorFormatter when using appRouter.createCaller

[Patrick-Ullrich]

Provide environment information

  System:
    OS: macOS 13.2.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 3.36 GB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
    Yarn: 1.22.18 - ~/.nvm/versions/node/v16.14.0/bin/yarn
    npm: 8.14.0 - ~/.nvm/versions/node/v16.14.0/bin/npm
  Browsers:
    Chrome: 111.0.5563.146
    Firefox: 111.0.1
    Safari: 16.3

"typescript": "4.9.5"
"@trpc/server": "^10.13.0",
"@trpc/client": "^10.13.0",
"@trpc/next": "^10.13.0",
"@trpc/react-query": "^10.13.0",

using @trpc/server 10.0.0 in reproduction

Describe the bug

When using trpc in the actual app with a middleware (e.g. Express middleware):

 trpcExpress.createExpressMiddleware({
                router: appRouter,
                createContext: createTRPCContextFromExpress,
            }),

The error formatter is being called as expected. In my tests where I simply call the router directly using createCaller, the error formatter is not being triggered.

Link to reproduction

https://stackblitz.com/edit/trpc-server-inferred-type-cannot-be-named-x2pseq?file=src/index.ts

To reproduce

See stackblitz

Additional information

For context, we try to keep trpc errors out of our application logic, so we use the errorFormatter to turn our own exceptions into trpc ones:

e.g.:

export const t = initTRPC
    .context<typeof createInnerTRPCContext>()
    .meta<Meta>()
    .create({
        errorFormatter({ error, shape }) {
            if (error.cause instanceof ValidationException) {
                return {
                    ...shape,
                    data: {
                        ...shape.data,
                        code: 'BAD_REQUEST',
                        httpStatus: 400,
                        errors: error.cause.errors,
                    },
                };
          ...

            let eventId = '';
            // Sentry
            if (process.env.NODE_ENV === 'production') {
                eventId = Sentry.captureException(error);
            }

            return {
                ...shape,
                data: {
                    ...shape.data,
                    code: 'INTERNAL_SERVER_ERROR',
                    httpStatus: 500,
                    message: "We're sorry, something went wrong.",
                    referenceId: eventId,
                },
            };
        },
    });

Without it being triggered we are actually just getting TRPCError in the tests which isn't that useful.

👨‍👧‍👦 Contributing

• 🙋‍♂️ Yes, I'd be down to file a PR fixing this bug!

[KATT]

This works as designed and would be a breaking change - the error formatting is specific for how responses are serialized before returning it in an API request.

That said, I understand the confusion and we could do some caller that does the complete serialization too.

[Nick-Lucas]

This works as designed and would be a breaking change - the error formatting is specific for how responses are serialized before returning it in an API request.

That said, I understand the confusion and we could do some caller that does the complete serialization too.

So having fielded the original query on discord, my sense is that anything we pass to initTRPC should work in every situation, including createCaller. Where we don't think that's appropriate it should be in the Adapter layer instead.

Might be one for #3496 or a future v12

[Patrick-Ullrich]

I figured this might be the reason. Personally, I looked at error formatter as part of the middleware which probably should be run when using the caller. But I can also sympathize for the choice of not doing so.

It be nice to be able to get it to run somehow though. Thoughts on introducing a... "TestAdapter" similar to Express / NextJS adapter that is a thin wrapper that would trigger the error formatter (and anything else it might need?). That way it wouldn't be a breaking change :)

If you could point me into the right direction (assuming taking a look at one of the adapters) or have some thoughts around it I could take a crack at it. - I am also now on the discord, happy to chat more there as well

[KATT]

My experience of doing my own integration testing is that you want all information possible even when things fails, including the original error etc. With this, you lose that.

I don't think we'll implement this. For now, I'd recommend you spin up a tRPC server for your tests and create a TRPCClient that you use if you want this behavior. This is how we do most of the testing within trpc itself to assure that our client packages work.

I understand that it is a bit confusing that we have the error formatter on the root object though considering it's only used in adapters.... API design is hard 😅

[KATT]

If this is blocking you, feel free to reopen or create another feature request on how we can change things to be more clear

[Patrick-Ullrich]

I appreciate the explanation - yeah, I think i'd still like an easier way to test that specific boundary without having to introduce a web host, but I totally get where you are coming from and I am sure there are more important features to work on.

If I wanted to create my own little adapter that does nothing but run the error formatter on top of it but could still be called using the create Caller... Do you think that be an easy task? If so, could you point me into the right direction? Issue can stayed closed though :)

Thanks again