Weird .refresh() behaviour with different schema libraries

[aevstratov]

Describe the bug

I am using arktype in my project and ran into an issue with query refresh. If i have schema with object shape and fill properties for command param in order different than i pass to query, i dont get a refresh. But once i do pass properties in the same order, refresh works as expected. I tried the same with valibot, but with valibot everything works fine

Reproduction

https://www.sveltelab.dev/eve63v4438x0y30?files=.%2Fsrc%2Froutes%2F%2Bpage.svelte%2C.%2Fsrc%2Froutes%2Fdata.remote.js

1. Hit second increment button - second counter should update
2. Try to change order of properties for getCounterWithParams() and incrementWithParams()
3. Go to the data.remote.js and uncomment second Param schema
4. Try to hit second increment button

Logs

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes   
  Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 20.19.1 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.8.2 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    svelte: ^5.43.4 => 5.43.4
    @sveltejs/kit": ^2.5.27

Severity

annoyance

Additional Information

No response

[Conduitry]

It looks like, in the validated form of the arguments, valibot will reorder object keys to match the order given in the schema, while arktype returns them in the order they were in the original object. I assume that SvelteKit's invalidation here does not perform its own normalization of objects before treating them as cache keys.

I'm not sure what we want to do here. I'm hesitant to say that it ought to be SvelteKit's responsibility to normalize the order of keys in all objects, when this will very often be a waste of time. This might be something we should just document.

[Conduitry]

Actually, thinking about this a little more, I don't think that we should assume that objects whose keys are in a different order are the same object. If you're using a validation library that doesn't normalize these, then, conceivably, { a, b } could have a different result from { b, a } if the remote function looked at key order.

IMO, this behavior should be - if anything - documented and not changed.