stub_response regression in aws-sdk-core >= 3.221.0 with quicksight sdk

[fcheung]

Describe the bug

With aws-sdk-core versions >= 3.221, calling a method on Aws::Quicksight::Client stubbed with stub_responses returns nil instead of the configured value

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

When calling the stubbed method I should get the stub data I provided, not nil. This is the observed behaviour with versions <= 3.220

Current Behavior

The reproduction below evaluates to nil when run against '3.221.0' (it's not really nil, but a Seahorse::Client::Response, whose getobj returns nil).

Reproduction Steps

gem 'aws-sdk-quicksight', '1.144.0'
gem 'aws-sdk-core', '3.221.0'

require 'aws-sdk-quicksight'
client = Aws::QuickSight::Client.new stub_responses: true
data = client.stub_data(:generate_embed_url_for_registered_user, embed_url: "http://example.com")

client.stub_responses(:generate_embed_url_for_registered_user, data)

puts client.generate_embed_url_for_registered_user(
user_arn: 'some-arn',
aws_account_id: '112233445566',
experience_configuration: {dashboard: {initial_dashboard_id: 'abc'}},
)

Possible Solution

No response

Additional Information/Context

The stubbed data looks like

#<struct Aws::QuickSight::Types::GenerateEmbedUrlForRegisteredUserResponse embed_url="http://example.com", status=0, request_id="String">

If I set status to 200 then when I call client.generate_embed_url_for_registered_user I get the expected result. At a guess the status of 0 causes

aws-sdk-ruby/gems/aws-sdk-core/lib/aws-sdk-core/rest/handler.rb

Line 11 in bb37f94

response.on(200..299) { |resp| Response::Parser.new.apply(resp) }

to not apply the stub body to the result.

From the description it sounds like #3204 might be relevant, but not sure what in the diff is the culprit

Gem name ('aws-sdk', 'aws-sdk-resources' or service gems like 'aws-sdk-s3') and its version

aws-sdk-quicksight=1.144; aws-sdk-core=3.221.0

Environment details (Version of Ruby, OS environment)

ruby 3.4.2 (in the ruby:3.4.2-alpine docker image)

[mullermp]

Thanks for opening an issue.

You are correct that the status may be why it is not being parsed. Based on what I modeled by the API, all three members are required:

https://github.com/aws/aws-sdk-ruby/blob/version-3/apis%2Fquicksight%2F2018-04-01%2Fapi-2.json#L13150

This was an intentional change. I'm sorry that it caused an issue for you - there were some edge cases I did not think of. stub_responses should be correctly validating against this if you do not use stub data. Can you please update your code to use stub_responses directly and set a status? The hash that you would have passed into stub_data can directly be applied to stub_responses, and it should give a validation error unless you provide all three values. Alternatively you can provide a status into the stub_data - I believe it fills out remaining values.

[fcheung]

Thanks - that does work. This feels quite unergonomic though:

• if I use stub_data then I get no feedback about missing values - the malformed stub is just silently ignored
• If I use stub_responses only then I also have to provide request_id (stub_data fills this in for you, and unlike status there's no branching based on this)

I feel like I'm doing a lot of boilerplate & having to worry about things at a lower layer of abstraction (eg it would be nonsensical to have this data exist if the response code isn't 200ish because then there is no result)

I can (and have) just stick this all in a factory, but the documentation for stub_data ("Generates and returns stubbed response data from the named operation") really makes it sound like it's doing it for you, whereas right now as far i can tell it's just copying the data into the correct class/structures.

[mullermp]

I understand where you are coming from. stub_data does just that - it fills in a struct with dummy data. We default all of the integer shapes to zero. I think this is an unfortunate consequence of a bad API. While supported and not recommended, this API has modeled the status code to a member of the body, rather than using the HTTP status of the response itself, which is quite odd.

=> #<struct Aws::QuickSight::Types::GenerateEmbedUrlForRegisteredUserResponse embed_url="http://example.com", status=0, request_id="String">

When setting status to 200, and embed_url to example.com, it returns the correct thing. I would recommend just adding status to your stub_data and it should work as expected.

I think what happened is that previously stub_data was passed as the stub directly whether it was correct or not. In this case it was not, and it was directly returned by the client call. With the new change, the stub_data is run through the protocol deserialization process, which unfortunately tripped you in this case. It unpacks the stubbed data and creates a mock HTTP response that gets parsed as if it came from the service.

I ultimately think while this is more verbose, it ensures that you are testing your application in accordance to what the service responds with (or is required to respond with) rather than some dummy struct or garbage data that would never be returned otherwise.

I personally think stub_data is useful if you have parts of your system that want to test handling the response from the client. I generally recommend using stub_responses only because it validates required members of the API, for both input and output.

[fcheung]

Thanks, that’s useful info. Maybe at some point the docs could steer people in that direction (or at least surface that some apis require a lot of verbosity, unlike the example in the docs which doesn’t require status or request id)

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.