Skip to content

Parse Input/Output When Operation Style is Document #114

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

Merged
merged 1 commit into from
Mar 26, 2023
Merged

Parse Input/Output When Operation Style is Document #114

merged 1 commit into from
Mar 26, 2023

Conversation

mattpolito
Copy link
Contributor

Problem:

When parsing operations of the Workday API we were getting incorrect input values. The operation here is not declared with a soapAction so it never made it into the logic to parse inputs/outputs.

Note:

Please review changes to specs. As far as we can tell the specs were not accurately describing parsing of inputs/outputs, hence the changes to reflect 'correct' parsing.

However, we fully understand that someone wrote the specs with those assertions in mind. So there is an expectation that they should work that way.

Please let us know if these assumptions are incorrect so we can try and adjust.

Co-authored-by: Matt Polito <[email protected]>
Co-authored-by: Tony Yunker <[email protected]>
@mattpolito
Copy link
Contributor Author

Any feedback on this one?

@pcai
Copy link
Member

pcai commented Mar 24, 2023

Thanks for your patience. I'm going through this today to try and understand the change

@@ -247,8 +248,7 @@ def input_output_for(operation, input_output)
port_type_operation = @port_type_operations[binding_type][operation_name]
end

port_type_input_output = port_type_operation &&
port_type_operation.element_children.find { |node| node.name == input_output }
port_type_input_output = port_type_operation&.element_children&.find { |node| node.name == input_output }
Copy link
Member

Choose a reason for hiding this comment

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

just noting this: the lonely operator was introduced in ruby 2.3x but this gem still declares compatibility with >= 1.9.2

in practice, this is most likely an oversight, as savon projects have a de facto policy of covering only supported rubies (1.9x isnt even covered in the test matrix)

@@ -15,7 +15,7 @@

it 'falls back to using the message type in the port element' do
# Operation's input has no part element in the message, so using the message type.
expect(subject.operations[:save][:input]).to eq('Save')
expect(subject.operations[:save][:input]).to eq("SaveSoapIn")
Copy link
Member

Choose a reason for hiding this comment

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

@pcai
Copy link
Member

pcai commented Mar 24, 2023

OK This seems good to me, sorry for the silly questions as I am no longer involved in an org that uses savon/wasabi, but my main concern is --

Is there any universe where the current behavior (without this PR) would be considered correct? In context these changes appear good, but I am somewhat apprehensive about merging this in, cutting a bugfix release, and then getting a complaint that it breaks someone's working code. If there's a risk of that, then perhaps a major version bump is in order?

Note that I have updated main branch to clarify we are 2.7+ so the use of lonely operator should not be an issue

@mattpolito
Copy link
Contributor Author

Thanks for taking a look. We were hoping you might have some insight into if it was a sane change. It works for us and obviously we made it so all tests pass. However we can only verify it against the wsdl we're currently using.

@pcai
Copy link
Member

pcai commented Mar 26, 2023

OK so in summary we aren't sure if this is safe but this fixes a problem with a well known provider, I assume this affects others we don't know about too. I will merge this and cut a release and we'll deal with any side effects as they come up. I will also do a major version bump alongside this for the change in supported ruby versions and to ensure this gets extra scrutiny downstream.

Thanks for your contribution.

@pcai pcai merged commit 299a671 into savonrb:master Mar 26, 2023
pcai added a commit that referenced this pull request Mar 26, 2023
@mattpolito
Copy link
Contributor Author

This seems like an appropriate move. Thanks for looking over it.

If you need help maintaining the savon repos, let me know. I'd like to help where you need it.

@pcai
Copy link
Member

pcai commented Mar 27, 2023

@mattpolito i would like to take you up on that, couldn't find your contact info and twitter dms seem broken 👎🏻 , can you email me?

@mattpolito mattpolito deleted the adjust-input-output-parsing branch March 28, 2023 16:14
@mattpolito
Copy link
Contributor Author

@pcai I reached out via email.

@pcai pcai mentioned this pull request Oct 27, 2024
pcai added a commit that referenced this pull request Oct 27, 2024
Fixes a regression introduced in #114
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants