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

RPC exceptions don't work as expected #602

Open
homier opened this issue Jan 10, 2025 · 4 comments
Open

RPC exceptions don't work as expected #602

homier opened this issue Jan 10, 2025 · 4 comments

Comments

@homier
Copy link
Contributor

homier commented Jan 10, 2025

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 homier changed the title RPC exceptions don't work properly RPC exceptions don't work as expected Jan 10, 2025
@homier
Copy link
Contributor Author

homier commented Jan 10, 2025

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.

@Semisol
Copy link
Contributor

Semisol commented Jan 12, 2025

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?

@kentonv
Copy link
Member

kentonv commented Jan 13, 2025

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.

@Semisol
Copy link
Contributor

Semisol commented Jan 13, 2025

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.

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

No branches or pull requests

3 participants