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

Simplify error handling in XML API - BREAKING CHANGE #1043

Merged
merged 4 commits into from
Jul 18, 2023
Merged

Conversation

graebm
Copy link
Contributor

@graebm graebm commented Jul 13, 2023

Issue:
It's hard to report errors with the current API. Errors are being accidentally ignored, and some errors are never checked (perhaps because it was too much effort?).

Diagnosis:
The current callback returns bool of whether to continue parsing, rather than our typical int/AWS_OP_SUCCESS/aws_raise_error() error handling.

This seems like a simple design. But the inconsistency in return type leads to errors being mistakenly swallowed. And it makes it hard when you do want to "bubble up" an error from the callback. Callbacks needs to store a custom error_code in their user_data to report an error. Most callbacks never bothered to do this, maybe because it was extra work?

Description of changes:

  • XML traversal callback returns int instead of bool.
    • If a callback fails, the whole parse() fails.
    • You can no longer stop parsing without causing failure. But in nearly all use-cases we were stopping due to error. I found 1 case where we stopped because we found what we were looking for. But in this case, it didn't really hurt to continue parsing. The reduced complexity seemed worth the change.
  • Remove aws_xml_parser_new(), aws_xml_parser_destroy(), aws_xml_parser_parse(), replace with aws_xml_parse().
    • The new() and destroy() calls were unnecessary. Removing them simplifies use.
  • aws_xml_node_get_name() just returns aws_byte_cursor(), instead of int
    • This can't fail. Changing the signature simplifies use.
  • Raise AWS_ERROR_INVALID_XML instead of AWS_ERROR_MALFORMED_INPUT_STRING
    • This change is more wishy-washy. It seemed useful to get this new, more specific, error code if it bubbling up from deep within some larger operation, like an S3 meta-request.

API BREAK:
We don't know any external uses of this API, so it seems safe to change. The API is only intended for internal use by the aws-c libraries, which are being fixed up now. This API was quickly written as private code in aws-c-auth (awslabs/aws-c-auth#40), then moved to public in aws-c-common (#674) when aws-c-s3 also needed to parse XML. The fact that it was originally private is why this API didn't get more scrutiny originally.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

More informative than AWS_ERROR_MALFORMED_INPUT_STRING if it boils up from some deep internal system.
* return true to continue the parsing operation.
*/
typedef bool(
aws_xml_parser_on_node_encountered_fn)(struct aws_xml_parser *parser, struct aws_xml_node *node, void *user_data);
typedef int(aws_xml_parser_on_node_encountered_fn)(struct aws_xml_node *node, void *user_data);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, if user wants to just stop parsing without error, they cannot do it now?

I guess we still have use case like I found the response I want and, now we can just stop parsing and it's not an error?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I saw the description.

To me, I feel like the complexity is not too bad, just one more boolean, while it helps to improve performance? I just don't like the idea of having to do the extra parsing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Only errors can stop the parser now.

I found that in all cases but one, we were returning false because an error happened.

My 1st pass did have an extra bool *stop_parsing param that the callback could set, but I got sick of ignoring the param ((void)stop_parsing;) in every callback. Also, the stop_parsing code paths were not well tested. I felt better just removing the feature.

It was only used in the aws_xml_get_top_level_tag() functions. I changed it so its callback just immediately returns if its called again after finding the one thing it's looking for.

But in most cases we're gathering data from a few elements (e.g. credentials provider needs access key, secret, expiration, etc) and didn't use it

@graebm graebm merged commit 5c736d5 into main Jul 18, 2023
51 checks passed
@graebm graebm deleted the xml-error-handling branch July 18, 2023 23:14
graebm added a commit to awslabs/aws-c-s3 that referenced this pull request Jul 18, 2023
**Issue**
The XML API was hard to use right, leading to bugs like this: #328

**Description of changes:**
- Adapt to API changes from: awslabs/aws-c-common#1043
- Break up node traversal functions, to ensure we're processing the correct XML elements.
    - Previously, the same callback would be used for all XML elements. This could cause error if an element with the same name occurred at different parts of the document tree.
- Improved error checking
    - Previously, many calls to `aws_xml_node_as_body()` weren't being checked for error.
- Replace ~aws_xml_get_top_level_tag()~ and ~aws_xml_get_top_level_tag_with_root_name()~ with `aws_xml_get_body_at_path()`
   - ~aws_xml_get_top_level_tag()~ didn't check the name of the root node
   - ~aws_xml_get_top_level_tag_with_root_name()~ was clunky to use (IMHO)
   - so replace with an API that can retrieve an element at any depth (not just 2), checking names the whole way, and with a nicer API (IMHO).
   - new function gives `aws_byte_cursor` instead of `aws_string`, the user was usually just deleting it afterwards, which made their error-handling more complicated.
- Trivial stuff:
    - Remove unused functions ~aws_s3_list_objects_operation_new()~ and ~aws_s3_initiate_list_parts()~
    - `aws_replace_quote_entities()` returns `aws_byte_buf` by value, instead of as out-param
    - Some functions take `aws_byte_cursor` by value, instead taking `aws_string *` or `aws_byte_buf *` or `aws_byte_cursor *` by pointer
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

Successfully merging this pull request may close these issues.

2 participants