Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vanilla Client: error deserializing procedure arguments #250

Open
v-morlock opened this issue Jan 10, 2024 · 1 comment
Open

Vanilla Client: error deserializing procedure arguments #250

v-morlock opened this issue Jan 10, 2024 · 1 comment

Comments

@v-morlock
Copy link

v-morlock commented Jan 10, 2024

When using the Vanilla client ("@rspc/client": "0.1.3",) to call this mutation on the currently published server (rspc = { version = "0.1.3", features = ["axum"] }
specta = { version = "1.0.5", features = ["chrono"] }
):

        .mutation("myprocedure", |t| {
            t(|s, _: ()| {
( ...)
            })
        })

like this:

	import { createClient, FetchTransport } from '@rspc/client';
	import type { Procedures } from '../../../../../../../../controls-rs/rspc.schema';
	const client = createClient<Procedures>({
		transport: new FetchTransport('http://localhost:4000/rspc'),
	});

client.mutation(['myprocedure'])

rspc returns this error:

{
    "jsonrpc": "2.0",
    "id": null,
    "result": {
        "type": "error",
        "data": {
            "code": 400,
            "message": "error deserializing procedure arguments",
            "data": null
        }
    }
}

I could reproduce the same behaviour with 1.0.0-rc.3. I guess the issue is that the vanilla client sends {} as request... Any ideas how to work around this or what a possible fix could look like? I'd be happy to submit a PR but could use some pointers on where to look for a solution

@cfmatthee
Copy link

cfmatthee commented Oct 15, 2024

Observed the same problem. A mutation without any arguments does not know what to do with the {} argument forwarded from the vanilla client. Turning tracing on showed that this is considered a Map.

Switching to the WebSocketTransport made the problem go away. Alternatively, adding a HashMap argument to the function call also made the problem go away. Not a fix. More of a hack until the real source of the problem can be located and fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants