Partial Sucess/Failure?

[ironside]

Hello!

I'm curious why JSON-RPC requires EITHER results or error and does not support both?

The workarounds I've seen to handle partial success/failure all seem a bit janky, 

Could the spec be updated to allow both results and error in a single response?

[Alex Korotkov]

It's sounds like an operation can be splitted into a batch of multiple jsonrpc-requests, each of which represents a certain part of a complex result.

пт, 23 мая 2025 г., 17:46 ironside <irons...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to json-rpc+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/json-rpc/d896f6e6-e727-44d0-ba4c-2bbd435e3c75n%40googlegroups.com.

[Tomáš Benedikt]

IMHO that shouldn't be possible. As name of protocol say, it's "Remote Procedure Call". That means somewhere remote is procedure, more likely method, which do certain job and it should success or fail. Semi-state seems more like poor algorithm structure. It's like saying that "3+5-1" results in "8" but at same time it sends you error "substract is not supported" and call this partial success.

Dne pátek 23. května 2025 v 19:38:46 UTC+2 uživatel durm.ic...@gmail.com napsal:

[ironside]

An example is an RPC which (often for the interest of reduced chatter) takes a payload that may result in multiple records being created in a database - perhaps one of those records is critical (and if fails, would result in a hard failure) but some are optional. If the critical record succeeds and optional records fail, we can express that in our api (which returns both a `response` and `errors` array, every time, but the `errors` array may be empty.

As for forcing it into a batch - that's a feature already supported by the standard, so I'm thinking here of cases where the operation performed is not just a simple repeat of a smaller operation.

[ironside]

Taking Tomas's analogy a bit further for sake of argument - say you have an API that expects an array of numbers, and the api is going to divide the number 200 by each input, creating a return array.

so passing [10,2] returns 200/10 = 20, 200/2 = 100 => [20,100]

To avoid making 100 separate network calls, you just pass in an array of 100 numbers.

If some of those numbers happen to be zero, you get divide-by-zero errors, but nonzero inputs are processed successfully.

This is a senseless example to prove a point - but in reality there can be business operations - usually something more complex than simple CRUD operations, which may result in partial success/failure like this.

[Martin Barker]

Reading through this, I concur that there are use cases for this sort of functionality. However, the specification technically allows for multiple responses.

It would be up to the client to handle this. The specification does not restrict you to sending only one response back. For example, if you are using WebSockets, you could send one request and receive multiple responses to that request. The "id" would remain the same as the request, but the data object in the error can provide more detailed information, which would include data such as sub-execution identification.

To view this discussion visit https://groups.google.com/d/msgid/json-rpc/99ef406c-c28e-4db2-a5c1-0a7d7f9e860bn%40googlegroups.com.