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

Address Protocol Tests that are breaking changes #3474

Merged
merged 4 commits into from
Sep 19, 2024

Conversation

peterrsongg
Copy link
Contributor

@peterrsongg peterrsongg commented Sep 12, 2024

Description

This addresses all the Protocol Tests which we deemed as breaking changes

  1. SimpleScalarPropertiesPureWhiteSpace: Xml responses that returned pure whitespace in the body of an xml element were being trimmed. For example => . Now we will return the whitespace as is without trimming it.
  2. RestJsonHttpPayloadTraitsWithNoBlobBody HttpPayloadTraitsWithNoBlobBody: If the payload of a response has no data, instead of returning an empty memory stream as the payload we will return null.
  3. Unmarshalling an attribute with @xsi: was not working, since @xsi is a prefix. We will now successfully unmarshall an attribute with a prefix.

Some refactoring of the tt files.
Some other tests were request level changes that weren't breaking but were fixed with the nullability changes (see empty lists/maps tests)

Note The other tests in the VNext list can't be addressed until we pull in the latest smithy version, since I added some additional tests for nestedXmlMapsWithXmlName. This would also cause us to pull in a lot of other protocol tests, so should be addressed in a separate PR. Those tests are not breaking changes so it is not critical to ship them in V4.

Motivation and Context

Need to address in major version as there are breaking changes.
DOTNET_7435

Testing

DRY_RUN passed in v4.
All protocol tests passed.

Screenshots (if appropriate)

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist

  • My code follows the code style of this project
  • My change requires a change to the documentation
  • I have updated the documentation accordingly
  • I have read the README document
  • I have added tests to cover my changes
  • All new and existing tests passed

License

  • I confirm that this pull request can be released under the Apache 2 license

{
"core": {
"changeLogMessages": [
"fix: address protocol tests that are breaking changes."
Copy link
Contributor

Choose a reason for hiding this comment

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

I would prefer this is a little more specific to what is breaking since this is the change log.

if (!withPrefix)
{
var locationNameString = locationName.ToString();
return locationNameString.StartsWith("xsi:") ? locationNameString.Substring(4) : locationNameString;
Copy link
Contributor

Choose a reason for hiding this comment

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

Is the prefix always going to be xsi or should we be doing a more generic prefix strip?

@@ -123,7 +123,9 @@ namespace <#=this.Config.Namespace #>.Model.Internal.MarshallTransformations
{
#>
if(<#=variableName + ".IsSet" + member.PropertyName#>())
xmlWriter.WriteAttributeString("<#=member.MarshallName#>", "<#=member.XmlNamespace#>",<#=member.PrimitiveMarshaller#>(<#=variableName#>.<#=member.PropertyName#>));
<#+
WriteXmlAttributeString(level + 1,member,variableName, isPayload: false);
Copy link
Contributor

Choose a reason for hiding this comment

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

readability: missing spaces after the ,s

var prefix = "";
var localName = "";
string ns = member.XmlNamespace;
if (member.MarshallName.StartsWith("xsi"))
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be generic prefix parsing instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just for some context

Normally a service would model it like this where they tell us the prefix. In that case we use the prefix provided

But in some cases the service will actually attach xsi to the locationName itself like this

Although no actual service does this, the protocol tests want to make sure we can handle that. The only other valid prefix from what I've seen is xsd (other than xsi), but I don't see a problem with just assuming everything before the first : is a prefix, since we can't unmarshall an attribute with a : in it anyways. Will make it more generic.

@@ -64,7 +64,7 @@ public IRequest Marshall(XmlAttributesRequest publicRequest)
{
xmlWriter.WriteStartElement("XmlAttributesRequest", "");
if(publicRequest.IsSetAttr())
xmlWriter.WriteAttributeString("test", "",StringUtils.FromString(publicRequest.Attr));
xmlWriter.WriteAttributeString("","test", "",StringUtils.FromString(publicRequest.Attr));
Copy link
Contributor

Choose a reason for hiding this comment

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

Is the extra space before xmlWriter intentional? If you're making a change, it'd also be good to add spaces between the ,, e.g.:

xmlWriter.WriteAttributeString("", "test", "", StringUtils.FromString(publicRequest.Attr))

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ah good catch, removed the extra indentation

#>
<#+
// xsi is a common prefix in attributes, but it cannot be included in the local name itself as the xmlWriter class will throw an exception.
// Some services may model the xmlName, with the xsi prefix included like it is here https://github.com/smithy-lang/smithy/blob/main/smithy-aws-protocol-tests/model/restXmlWithNamespace/main.smithy#L147
Copy link
Contributor

Choose a reason for hiding this comment

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

Small nit: In the GitHub UI, you can right click that line and select Copy permalink.

I don't know how often those protocol tests change, but if they do line 147 on the main branch may not be the same.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

cool tip! didn't know about that. just updated

@peterrsongg peterrsongg merged commit 4999792 into v4-development Sep 19, 2024
1 check passed
@peterrsongg peterrsongg deleted the petesong/address-v4-protocol-tests branch September 19, 2024 20:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants