Date deserialization in TRPC mutations not working in edge runtimes

[aldebout]

Cross-posting t3-oss/create-t3-turbo#1110 to get your eyes on it 😉

It looks like superjson silently fails to deserialize Date objects in edge runtimes, only in TRPC mutations (not queries).

More details in the original issue, including repro.

[Skn0tt]

Interesting, thank you! If you can come up with a minimal repro of this that behaves similar to how TRPC uses SuperJSON, but that doesn't include TRPC itself, then i'm happy to take a look and see if there's something to fix here.

[aldebout]

@Skn0tt here is a repro repo https://github.com/aldebout/superjson-edge-repro.
It's the nextjs app start with only superjson added.

To see the issue: pnpm i, pnpm dev, then post

{
    "json": {
        "startDate": "2024-12-20T14:00:00.000Z"
    },
    "meta": {
        "values": {
            "startDate": [
                "Date"
            ]
        }
    }
}

on /api.

If we set the runtime to node (export const runtime = 'nodejs') it works, if we set it to edge (export const runtime 'edge') it fails.

[aldebout]

Playing with it some more, it looks like there's an issue in both serialization and deserialization of Dates in the local nextjs edge runtime. If I serialize { startDate: new Date("2024-12-20T14:00:00.000Z") }, then result.json.startDate instanceof Date is true.

I tried running the tests using environment: 'edge-runtime' in vitest.config.mjs but they're still passing, I'm wondering if I'm missing something.

[Skn0tt]

Take a look at the code around

superjson/src/transformer.ts

Lines 79 to 84 in 0130a80

	simpleTransformation(
	isDate,
	'Date',
	v => v.toISOString(),
	v => new Date(v)
	),

and specifically at the implementation of isDate. I'm not very familiar with the internals of edge-runtime, but I could imagine that their Date implementation behaves slightly different from what SuperJSON expects, and from what happens on Node.js and in the browser. Try testing it exclusively within production - it seems like running edge-runtime locally is very different from prod: https://edge-runtime.vercel.app/#using-the-edge-runtime-locally

[aldebout]

I'll switch the runtime depending on the environment and let you know how it goes.

I was looking into the source code but I'm having issues linking and debugging locally so I'll take a break from that.

FWIW undefined is also broken in this setup, I'm wondering what the pattern is.

[aldebout]

The runtime switch is hard because nextjs requires a statically analyzable export :/

I dug deeper and the issue looks very similar to #242: in my local nextjs edge env,

superjson/src/is.ts

Line 16 in 0130a80

return Object.getPrototypeOf(payload) === Object.prototype;

returns false even though I have a plain object.

I don't really know how to fix this because (as you said) it's not very clear to me what exactly runs nextjs edge locally. In the meantime I think I'll switch to another lib.

[Skn0tt]

I could imagine that the NaN check here doesn't work on Edge runtime:

superjson/src/is.ts

Line 47 in 0130a80

payload instanceof Date && !isNaN(payload.valueOf());

If you or anybody else ends up doing more investigation on this, please post your results. Happy to write a fix.

[dotboris]

I've hit this issue myself but I'm not running on vercel's edge runtime. Instead, I got this issue in Jest.

Initially, this manifested itself as SuperJSON failing to deserialize a Date when running in Jest even when the payload format is valid. I've debugged the code and this fails in the same part of the code as this issue:

superjson/src/is.ts

Line 16 in dbf1024

return Object.getPrototypeOf(payload) === Object.prototype;

Specifically, Object.getPrototypeOf(...) === Object.prototype returns false when it should really return true. From my testing, it only seems to return false when running in Jest.

I've managed to narrow it down to a single difference between Jest's environment and a regular node environment: The return value of fetch(...).json() (getting the JSON body of a response with fetch) fails the above check only in jest.

I've made a simple repro to show this difference: https://github.com/dotboris/jest-fetch-json-proto-mangle

To be specific. The following passes:

async function main() {
  const httpRes = await fetch("https://jsonplaceholder.typicode.com/todos/1");
  const json = await httpRes.json();
  const pass = Object.getPrototypeOf(json) === Object.prototype;
  if (pass) {
    console.log("PASS");
    process.exitCode = 0;
  } else {
    console.log("FAIL");
    process.exitCode = 1;
  }
}

main().catch((err) => {
  console.error(err);
  process.exitCode = 2;
});

But the equivalent Jest test fails:

test("jest case", async () => {
  const res = await fetch("https://jsonplaceholder.typicode.com/todos/1");
  const json = await res.json();
  expect(Object.getPrototypeOf(json) === Object.prototype).toBe(true);
});

This doesn't sound like a SuperJSON bug to me but I wanted to share here in case it might help. I guess that SuperJSON cloud try to work around this somehow but I don't feel that it's the right approach.

[dotboris]

I've managed to find a decent workaround for this problem. I pass my own fetch wrapper to httpLink which recreates the result of res.json():

return createTRPCClient<...>({
  links: [
    httpLink({
      url: `...`,
      transformer: SuperJSON,
      fetch: async (input, init) => {
        const res = await fetch(input, init);
        const origJson = res.json.bind(res);
        res.json = async () => {
          const json = await origJson();
          const reprocessed = JSON.parse(JSON.stringify(json));
          return reprocessed;
        };
        return res;
      },
    }),
  ],
});

The json parse + stringify combo is a little shady but in the case of tests, it's acceptable.

For context, I did some more digging and I believe that this happens because Jest runs tests in isolated environments using node's vm module. In that context, there's two instances of Object: one inside the env and one outside the env. fetch seems to use the one outside the test environment while SuperJSON uses the one inside the test environment.

One thing that SuperJSON could do here is make its isPlainObject check tolerant of this by checking if the name of the prototype is Object instead of comparing references directly. That would make it more resistant to running in isolated environments.