Unexpected behavior from waiter if timeout provided

[oleg-rd]

Describe the bug

Based on the documentation it is possible to override the default configuration of the waiter. One of the example demonstrates the option to provide custom timeout - o.waitTimeout(Duration.ofMinutes(1)). So the expectation in this case that overall amount of time that waiter is going to be waiting should be based on that provided timeout. However, waiter could be stopped earlier if it reaches maxAttempts, that defaults to 100.

For example, if we set waitTimeout as Duration.ofMinutes(30) - it won't work like that. Waiter will be stopped after 10 minutes, because it has 100 attempts and 6s between them provided by default.

Regression Issue

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

Expected Behavior

Either skip maxAttempts (do not set it as default = 100) or recalculate it in runtime based on provided timeout if overridden configuration provided

Current Behavior

Waiter with overridden configuration doesn't work as expected

Reproduction Steps

        WaiterOverrideConfiguration waiterOverrideConfiguration = WaiterOverrideConfiguration.builder()
                .waitTimeout(Duration.ofSeconds(30))
                .build();

Possible Solution

If the described behavior considered as valid and expected, please at least update the documentation to mention this as it is really confusing at the moment. However, I still consider not convenient to force users to recalculate amount of attempts manually if they just want to focus on timeout.

Additional Information/Context

No response

AWS Java SDK version used

2.29.43

JDK version used

11

Operating System and version

Windows 10

[bhoradc]

Hi @oleg-rd,

Thank you for reporting the issue. I am unsure which service waiter you are trying to use here. But irrespective of that, the default values are coming from the respective AWS services. For reference - DynamoDB service waiters.

The WaiterOverrideConfiguration is indeed intended to allow users to override the default configurations, but it does not automatically adjust other related parameters. When you override the waitTimeout parameter, the maxAttempts value remains at its default unless explicitly overridden as well. To correctly override the waiter behavior, you would need to explicitly set all relevant parameters when deviating from the service defaults.

By documentation improvement, are you referring to the "Override configuration for a specific request" section, where an example with waitTimeout is shown without overriding the maxAttempts?

Regards,
Chaitanya

[github-actions]

It looks like this issue has not been active for more than five days. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please add a comment to prevent automatic closure, or if the issue is already closed please feel free to reopen it.

[oleg-rd]

Hi @bhoradc,
thanks for providing the information. In my case, I'm using waiter in context of ECS service -- and you are right, seems like default values are coming from it, so that I can see parts like

int maxAttempts = (Integer)optionalOverrideConfig.flatMap(WaiterOverrideConfiguration::maxAttempts).orElse(100);

My main point is still same - I really believe that current implementation is not user-oriented for a few reasons.

First of all, user has to figure out default values somehow. What is the expected way for that? They are not mentioned in the documentation.
Second point, user has to track the changes of those default values - what would happen if in a week or month they will be changed? For me it really looks like a poor design as it would be really tricky to trace such issues.
Third point - user has to calculate other values even if they don't care much about them.

What I'm trying to say, that for me it looks like a separate use-cases. One of those -- I need to wait during particular amount of time. In this scenario, I don't really care about the amount of attempts (but default value breaks my expectation). I also don't care much about the delay between those attempts (default value is fine here).

Hope that makes sense.