go-capnp icon indicating copy to clipboard operation
go-capnp copied to clipboard

RPC exceptions don't work as expected

Open homier opened this issue 11 months ago • 4 comments

It's really tricky to understand, how can I return a logic exception to a client. At the moment we've got the exc package that should help us return meaningful errors to clients by setting Type and Prefix to an exception, for instance let's create an instance of Failed type exception annotated with custom prefix, which I want my client to receive:

var ErrAccessKeySignatureMismatched = exc.Annotate("E_ACCESS_KEY_SIGNATURE_MISMATCHED", "signature mismatched", errors.New("omitted cause error"))

Then, in a server handler, I'd like to send that created exception to a client:

func (h *Handler) HandleSomething(ctx, call) error {
    ...
    if signatureMismatched {
        return ErrAccessKeySignatureMismatched
    }
    ...
    return nil
}

And I expect my go-capnp client to receive that error, and it indeed receives it:

resolver/resolver.capnp:Resolver.resolveTransferHandler: E_ACCESS_KEY_SIGNATURE_MISMATCHED: signature mismatched

But when I cast received err to an exception, prefix in the cast exception is empty, so I can't match it directly to the root cause without some string parsing. See the following example:

func UnmarshalError(err error) error {
	ce, ok := err.(*exc.Exception)
	if !ok {
		return err
	}

        // exists is false, because ce.Prefix == ""
	if err, exists := ErrorsByPrefix[ce.Prefix]; exists {
		return err.Unwrap()
	}

	return err
}

I might've been lost in terms of capnproto protocol errors handling and producing, but seems like clearly something is broken with exception prefixes. Or maybe I just didn't find how to properly parse exceptions :)

P.S. Regardless if this issue is a bug or not, I think we need to improve documentation for exceptions.

homier avatar Jan 10 '25 16:01 homier

I guess it happens because RPC server wraps any error from handlers to an exception, even if a returned error is already an error of type exc.Exception. Or the opposite - an exception is sent to a client, but the client doesn't try to interpret it as exc.Exception. If someone else confirms that this is not how it should work, I could probably make a PR to fix this.

homier avatar Jan 10 '25 17:01 homier

The current code does not handle decoding of prefixes.

cc @kentonv, is there any interest in standardizing attaching arbitrary capnp structs to be attached to Exceptions?

Semisol avatar Jan 12 '25 12:01 Semisol

In the C++ implementation's v2 branch we've added a notion of "exception details" which are arbitrary byte-blob attachments tagged with 64-bit type IDs. I suppose you could use that.

kentonv avatar Jan 13 '25 17:01 kentonv

In the C++ implementation's v2 branch we've added a notion of "exception details" which are arbitrary byte-blob attachments tagged with 64-bit type IDs. I suppose you could use that.

Somehow, I have missed that in the RPC specification. Thanks.

Semisol avatar Jan 13 '25 17:01 Semisol