Waiters #292
Waiters #292
Conversation
| end | ||
| expect_any_instance_of(waiter).to receive(:delay).and_wrap_original do |m, *args| | ||
| delay = m.call(*args) | ||
| expect(delay).to equal(5) |
There was a problem hiding this comment.
This test case is an example of the question I had in my doc regarding waiter retries. Because the remaining time (5) minus the delay (value between min delay of 3 and max delay of 4) is less than the min delay, the final delay value is set to be equal to the remaining time, which is 5. However, this exceeds the max delay. Is this expected behavior?
| }.to raise_error(no_such_waiter_error) | ||
| end | ||
|
|
||
| it 'does not allow custom waiters' do |
There was a problem hiding this comment.
Interesting. While true, I guess this documents that? I don't think it's needed but you can keep it if you want. I did not add one for paginators.
There was a problem hiding this comment.
Depending on whether or not we want to support registering new custom waiters this test case may be modified or removed.
There was a problem hiding this comment.
I'd say just remove it - it's cruft that can break and relies on modifying api private information.
| @@ -0,0 +1,4 @@ | |||
| # frozen_string_literal: true | |||
|
|
|||
| require_relative 'waiters/poller' | |||
There was a problem hiding this comment.
I would just place these in smithy-client.rb. This file is not big enough to justify loading.
| @@ -3,6 +3,44 @@ | |||
| module Smithy | |||
| module Client | |||
| module Errors | |||
| # Raised when a waiter detects a condition where the waiter can never | |||
| # succeed. | |||
| class WaiterFailed < StandardError; end | |||
There was a problem hiding this comment.
I'm not sure where the conversation went, but I think we want these in Smithy::Client::Waiters (but not have an Errors module inside there - just define the errors classes in the waiter namespace in the file where they are raised).
| @acceptors.each do |acceptor| | ||
| return acceptor['state'] if acceptor_matches?(acceptor['matcher'], output) | ||
| end | ||
| if output.error.nil? |
| equal?(actual, path_matcher['expected'], path_matcher['comparator']) | ||
| end | ||
|
|
||
| def matches_inputOutput?(path_matcher, output) # rubocop:disable Naming/MethodName |
There was a problem hiding this comment.
For these comments, you can disable once above this method and enable once again after the last method.
| end | ||
|
|
||
| def matches_success?(path_matcher, output) | ||
| if path_matcher == true |
|
|
||
| describe 'waiter' do | ||
| before(:each) do | ||
| shapes['smithy.ruby.tests#GetWidget']['traits']['smithy.waiters#waitable'] = { |
There was a problem hiding this comment.
What I was trying to say in slack is that you can actually define in GetWidget
'traits' => { 'smithy.waiters#waitable' => matchers }
and then in contexts, instead of before(:each) blocks, you can just do
let(:matchers) { .. }
| before(:each) do | ||
| shapes['smithy.ruby.tests#GetWidget']['traits']['smithy.waiters#waitable'] = { | ||
| 'SuccessTrueMatcher' => { | ||
| 'acceptors' => [ |
There was a problem hiding this comment.
In general, long, simple line JSONs should be shortened. You can put state, matcher, and success on one line
| end | ||
| end | ||
|
|
||
| context 'flatten' do |
There was a problem hiding this comment.
Is flatten a real matcher? Let's use the terminology from https://smithy.io/2.0/additional-specs/waiters.html
| output = { | ||
| children: [ | ||
| { | ||
| grandchildren: [ |
| context 'and inequality' do | ||
| before(:each) do | ||
| shapes['smithy.ruby.tests#GetWidget']['traits']['smithy.waiters#waitable'] = { | ||
| 'AndInequalityMatcher' => { |
There was a problem hiding this comment.
This is a fundamental difference I think between kotlin's approach and ruby - I don't know if we care to test things like flatten/and inequality, etc - These are really testing JMESPath implementations. I don't think Kotlin has a runtime JMESPath implementation like we do. I think we care to test the basic waiter matcher types (like booleanEquals) and we can rely on the fact that JMESPath handles "&&" expressions without having to test it here. So I think you can cut a good chunk of the tests in this file.
Description of changes:
Support the
#waitabletrait with waiters. Customers can use code generated waiters throughclient.wait_until(:waiter_name, params, options).By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.