-
Notifications
You must be signed in to change notification settings - Fork 190
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
Implement waiters #3595
Implement waiters #3595
Conversation
6c256e1
to
15ef73d
Compare
A new generated diff is ready to view.
A new doc preview is ready to view. |
/// Wraps `v` in tracking associated with this builder | ||
fn tracked<T>(&self, v: Option<T>) -> Option<Tracked<T>> { | ||
v.map(|v| Tracked::new(self.builder_name, v)) | ||
} | ||
} | ||
|
||
// TODO(waiters): Decide if this is the right approach for extracting sleep_impl/time_source |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the only big outstanding question on this PR. How exactly do we want to access components outside of the orchestrator prior to validation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whats the alternative? What are your concerns with this approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can think of a couple of alternatives:
- Add getter functions to
RuntimeComponentsBuilder
, or - Create a
OptionalRuntimeComponents
struct that is analog toRuntimeComponents
, but where creation doesn't do validation, and all the components in it are wrapped inOption
. TheRuntimeComponentsBuilder
would have abuild_optional
function to create this.
The current approach is limited to time/sleep. In the future, some other non-time related component may be needed outside of the orchestrator. Given that, I think these alternatives would be better, but then it's just a matter of picking between them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think what you have is a one way door so I'm not too concerned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks great! Few questions and some discussion.
...oftware/amazon/smithy/rust/codegen/client/smithy/generators/client/FluentBuilderGenerator.kt
Show resolved
Hide resolved
.../software/amazon/smithy/rust/codegen/client/smithy/generators/error/ServiceErrorGenerator.kt
Show resolved
Hide resolved
...in/software/amazon/smithy/rust/codegen/client/smithy/generators/waiters/WaitableGenerator.kt
Show resolved
Hide resolved
...in/software/amazon/smithy/rust/codegen/client/smithy/generators/waiters/WaitableGenerator.kt
Outdated
Show resolved
Hide resolved
/// time being exceeded, or some other failure occurring. | ||
#[derive(Debug)] | ||
#[non_exhaustive] | ||
pub enum WaiterError<O, E> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice
/// Wraps `v` in tracking associated with this builder | ||
fn tracked<T>(&self, v: Option<T>) -> Option<Tracked<T>> { | ||
v.map(|v| Tracked::new(self.builder_name, v)) | ||
} | ||
} | ||
|
||
// TODO(waiters): Decide if this is the right approach for extracting sleep_impl/time_source |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whats the alternative? What are your concerns with this approach?
A new generated diff is ready to view.
A new doc preview is ready to view. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still going through the PR, but looks great so far. One clarifying question. .customize
and .wait_XXX
on a fluent builder cannot be used together, i.e. the following is not supported?
client
.operation()
.customize()
.config_override(...)
.wait_until_XXX
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent work! In codegen diff, I see the doc on a waiter's fluent builder look like
impl ImageExistsFluentBuilder {
/// Creates a new `DescribeImages`.
pub(crate) fn new(handle: ::std::sync::Arc<crate::client::Handle>) -> Self {
Self {
handle,
inner: ::std::default::Default::default(),
}
}
It says /// Creates a new DescribeImages
but not /// Creates a new ImageExistsFluentBuilder
or /// Creates a new ImageExists
. Is that expected?
I opted to not support this yet without better understanding the use-case for it. It won't be hard to add if a good reason comes up. |
No, this is a bug. Fixed in 8a3d012 |
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
This PR implements waiters according to the Smithy waiters spec.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.