bug: superjson not transforming Dates for trpc mutations

[McCulloughRT]

Provide environment information

System:
OS: macOS 14.5
CPU: (8) arm64 Apple M2
Memory: 72.06 MB / 16.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 20.14.0 - ~/.nvm/versions/node/v20.14.0/bin/node
npm: 10.7.0 - ~/.nvm/versions/node/v20.14.0/bin/npm
pnpm: 9.5.0 - ~/.nvm/versions/node/v20.14.0/bin/pnpm
bun: 1.1.12 - ~/.bun/bin/bun
Watchman: 2024.05.06.00 - /opt/homebrew/bin/watchman

Describe the bug

when performing a trpc mutation, the superjson transformer on the server/api side does not appear to transform serialized dates back into date objects, even though network logs show it is serializing it properly on the client side. It just stays as a string. This results in a zod error if the mutation has a zod input validator that specifies "z.date()" (as well as any other error you might expect down the line from having the wrong type).

When using a trpc query with the same data (just an object with a date in it), superjson serializes and parses it without issue on both client and server.

I expanded the transformer initialization in /packages/api/src/trpc.ts to explicitly log the input values superjson recieves and returns in the transformer chain and it does appear that, given the same input from the client, in both queries and mutations trpc is providing the exact same data into the transformer argument, but for a reason I can't understand superjson seems to selectively transform only the queries and leaves the mutations unchanged.

Link to reproduction

https://github.com/McCulloughRT/date-example

To reproduce

See the linked repo, taking note of apps/nextjs/src/app/dateTest and packages/api/src/router/dateTest
Loading the page will issue a query that takes a date object as a param, validated in the router by zod to be a date successfully. Clicking the button will issue a mutation that takes a date object as a param, failing validation in the router to be a date.

Additional information

It's unclear to me if superjson is the issue, or trpc, or something I haven't thought of. I'm not sure how superjson could tell the difference between a query and a mutation if all the transformer is passing in is identical objects from trpc.

[juliusmarminge]

did you try repro this in a minimal trpc setting?

just trying to narrow down the search before digging in

[McCulloughRT]

Here's a minimal version that does not experience this issue using the trpc "getting started" as a guide, but with superjson and the package versions currently specified in the t3-turbo package.json:

https://github.com/McCulloughRT/trpc-test

So it's something about the way they're coming together in t3-turbo?

[McCulloughRT]

Building on this, here is a minimal example, working fine, using create-next-app and version matching trpc and superjson and tanstack/react-query to t3-turbo:

https://github.com/McCulloughRT/next-trpc

[aldebout]

@McCulloughRT I stumbled upon this issue because I was experiencing the same thing locally (I haven't yet tried anything actually deployed).

What fixes it (as a short term solution) for me is to switch to the non-edge environment by commenting out export const runtime = "edge"; in route.ts. It looks like you could have the same problem, since you have that line in your repro repo but not in the working one. Is it the same for you?

@juliusmarminge I tried digging a little deeper but without much success, it sounds very similar to flightcontrolhq/superjson#242 that has been fixed a while ago.

System:
OS: macOS 14.5
CPU: (8) arm64 Apple M1 Pro
Memory: 87.97 MB / 32.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 20.16.0 - ~/.nvm/versions/node/v20.16.0/bin/node
npm: 10.8.1 - ~/.nvm/versions/node/v20.16.0/bin/npm
pnpm: 9.6.0 - ~/.nvm/versions/node/v20.16.0/bin/pnpm
Watchman: 2024.07.15.00 - /opt/homebrew/bin/watchman

"@trpc/client": "11.0.0-rc.364",
"@trpc/react-query": "11.0.0-rc.364",
"@trpc/server": "11.0.0-rc.364",
"next": "^14.2.3",
"superjson": "2.2.1",
"zod": "^3.23.6"

[ViliusVZ]

@juliusmarminge I've encountered the same issue and disabling edge runtime like @aldebout suggested does indeed work. Do you have any ideas how to properly fix this?

[ochicf]

Same issue here. After some investigation, I noticed this only happens in mutations, so when the superjson handles it from the request body. Queries work well (though I've noticed that the value passed to transformer.deserialize contains Date instances already).

For now I'll swap to devalue as stated in this comment trpc/trpc#4515 (comment)

I would propose to that the API package exports the transformer from a module (ex: @acme/api/transformer) so it can be used in all places (api, nextjs and expo). This way swapping transformers would be as easy as change it in that file. I'll create a PR.