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

CCF's JSON adapter exceptions are not correctly logged #113

Open
letmaik opened this issue Feb 21, 2023 · 2 comments
Open

CCF's JSON adapter exceptions are not correctly logged #113

letmaik opened this issue Feb 21, 2023 · 2 comments
Labels
bug Something isn't working
Milestone

Comments

@letmaik
Copy link
Member

letmaik commented Feb 21, 2023

Currently, those exceptions are logged as "Unhandled exception in endpoint" since they are not HTTPError instances. CCF handles those exceptions and translates them to OData errors here:

https://github.com/microsoft/CCF/blob/6f365683de8d04bc0a37c3732c1de608989fb14e/src/node/rpc/frontend.h#L606-L619

I think we should duplicate this code so that we control the HTTP response and can then log it properly.

We could wrap CCF's JSON adapter into our own JSON adapter and emit HTTPError instances, for example.

@letmaik letmaik added the bug Something isn't working label Feb 21, 2023
@plietar
Copy link
Contributor

plietar commented Feb 21, 2023

I think we want to be careful not to turn any JSON errors into 400s, but instead just the ones that come from parsing the POST body.

If we have a json parsing error somewhere else in the stack (eg. DID resolution), we should handle that there and return a different error. If we have unexpected/unhandled json errors then we should keep returning a 500 error.

@ivarprudnikov ivarprudnikov added this to the 0.5.0 milestone Sep 12, 2023
@ivarprudnikov ivarprudnikov modified the milestones: 0.5.0, 0.6.0 Nov 3, 2023
@achamayou
Copy link
Member

The v4 adaptor supports defining error callbacks: microsoft/CCF#5241

It's also worth noting that SCRAPI has moved to CBOR for errors (among other things): https://github.com/ietf-wg-scitt/draft-ietf-scitt-scrapi/pull/38/files

It does make sense to consistently return CBOR, rather than CBOR in the successful path, and JSON on errors, and will simplify client-writing, it is something we should consider.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants