-
Notifications
You must be signed in to change notification settings - Fork 193
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
Add support for BehaviorMajorVersions #3151
Conversation
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. |
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. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
84568fe
to
a6e8c21
Compare
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, I like the direction this is headed. Nice work!
/// | ||
/// Over time, new best-practice behaviors are introduced. However, these behaviors might not be backwards | ||
/// compatible. For example, a change which introduces new default timeouts or a new retry-mode for | ||
/// all operations might be the ideal behavior but could break existing applications. |
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.
Add: If this is a concern, then explicitly set the version you want rather than using latest
. Then you can upgrade to newer behaviors and do adequate testing at your leisure.
<!-- The "Terminology" section is optional but is really useful for defining the technical terms you're using in the RFC --> | ||
Terminology | ||
----------- | ||
|
||
- **Some Term**: A definition for that term |
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.
Delete it if you're not going to fill it in
|
||
If no `BehaviorMajorVersion` is set, the client will panic during construction. | ||
|
||
`BehaviorMajorVersion` is an opaque struct with initializers like `::latest()`, `::v2023_11_09()`. Downstream code can check the version by calling methods like `::supports_v1()` |
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 the supports_*()
would work or be useful since the function wouldn't exist in a sufficiently old SDK. I think if we were to support something like this, we would need to have from_str
and supports_str
methods on the BMV.
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.
sufficently old SDKs won't have the newer code so there's no new versions to suppress
} | ||
``` | ||
|
||
We also will add `BehaviorVersionLatestRuntimePlugin`, a runtime plugin that is enabled when the `behavior-version-latest` feature is enabled in runtime crates. |
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.
Seems to me that these BMV plugins should be aggregate plugins that delegate to a bunch of other default RPs. Then the default RPs would no longer be configured on the client, but rather, just a single BMV plugin. That will cut down a lot on Arc<dyn>
thrash since the BMV can directly refer to the RP type rather than making it into a trait object.
Separately, are there any use cases for registering a normal or override-level RP with BMVs?
/// If, however, you're writing a service that is very latency sensitive, or that has written | ||
/// code to tune Rust SDK behaviors, consider pinning to a specific major version. | ||
/// | ||
/// The latest version is currently [`BehaviorMajorVersion::v1`] |
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.
/// The latest version is currently [`BehaviorMajorVersion::v1`] | |
/// The latest version is currently [`BehaviorMajorVersion::v2023_11_09`] |
Self {} | ||
} | ||
|
||
/// This method returns the behavior configuration for November 9th 2023 |
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.
/// This method returns the behavior configuration for November 9th 2023 | |
/// This method returns the behavior configuration for November 9th, 2023 |
@@ -337,7 +337,7 @@ mod test { | |||
.headers_mut() | |||
.try_insert("a\nb", "a\nb") | |||
.expect_err("invalid header"); | |||
let _ = req.headers_mut().insert("a\nb", "a\nb"); | |||
//let _ = req.headers_mut().insert("a\nb", "a\nb"); |
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.
?
From offline conversation: We decided the BMV shouldn't be a runtime component nor in the config bag because there should be no way to change it from inside of orchestration. It needs to be a special field in the service config, separate from components and the layer. Then it can be passed in as a constructor arg to the runtime plugins that need it, and those runtime plugins can add things to the config bag to tell components further downstream how to behave. |
4f398fa
to
685afc1
Compare
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.
Love the idea of pinning when loading defaults.
---------------------------------------------- | ||
|
||
In the current version of the SDK, users can construct clients without indicating any sort of behavior major version. | ||
Once this RFC is implemented, there will be three ways to set a behavior major version: |
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.
Once this RFC is implemented, there will be three ways to set a behavior major version: | |
Once this RFC is implemented, there will be two ways to set a behavior major version: |
Self {} | ||
} | ||
|
||
/// Returns whether V1 behaviors are enabled. |
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.
/// Returns whether V1 behaviors are enabled. | |
/// Returns whether V2023_11_09 behaviors are enabled. |
85e881a
to
d6a5881
Compare
A new generated diff is ready to view.
A new doc preview is ready to view. |
877edf5
to
6220b61
Compare
A new generated diff is ready to view.
A new doc preview is ready to view. |
6220b61
to
708c75f
Compare
A new generated diff is ready to view.
A new doc preview is ready to view. |
@@ -117,7 +118,7 @@ mod tests { | |||
#[tokio::test] | |||
async fn profile_name_override() { | |||
let fs = Fs::from_slice(&[("test_config", "[profile custom]\nsdk_ua_app_id = correct")]); | |||
let conf = crate::from_env() | |||
let conf = crate::from_env_with_version(BehaviorMajorVersion::latest()) |
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 we should rename this to defaults_with_version
, and load_from_env_with_version
to load_defaults_with_version
. In fact, maybe even remove the _with_version
part.
|
||
To help customers migrate, we are including `from_env` hooks that set `behavior-version-latest` that are _deprecated_. This allows customers to see that they are missing the required cargo feature and add it to remove the deprecation warning. | ||
|
||
Internally, `BehaviorMajorVersion` will become an additional field on `<client>::Config`. It is _not_ ever stored in the `ConfigBag` or in `RuntimePlugins`. |
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.
Would be nice to add how the BMV will be incorporated into RuntimePlugins via constructors and separate config bag values.
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.
done
A new generated diff is ready to view.
A new doc preview is ready to view. |
Motivation and Context
See rendered RFC
Description
This add
BehaviorMajorVersions
to the SDK and wires them in up and down the stack.Testing
Checklist
CHANGELOG.next.toml
if I made changes to the smithy-rs codegen or runtime cratesCHANGELOG.next.toml
if I made changes to the AWS SDK, generated SDK code, or SDK runtime cratesBy submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.