Skip to content
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

Merged
merged 9 commits into from
Nov 14, 2023
Merged

Add support for BehaviorMajorVersions #3151

merged 9 commits into from
Nov 14, 2023

Conversation

rcoh
Copy link
Collaborator

@rcoh rcoh commented Nov 8, 2023

Motivation and Context

See rendered RFC

Description

This add BehaviorMajorVersions to the SDK and wires them in up and down the stack.

Testing

  • lots of ITs / UTs

Checklist

  • I have updated CHANGELOG.next.toml if I made changes to the smithy-rs codegen or runtime crates
  • I have updated CHANGELOG.next.toml if I made changes to the AWS SDK, generated SDK code, or SDK runtime crates

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Copy link

github-actions bot commented Nov 8, 2023

A new generated diff is ready to view.

A new doc preview is ready to view.

Copy link

github-actions bot commented Nov 8, 2023

A new generated diff is ready to view.

A new doc preview is ready to view.

Copy link

github-actions bot commented Nov 8, 2023

A new generated diff is ready to view.

A new doc preview is ready to view.

@rcoh rcoh marked this pull request as ready for review November 9, 2023 15:19
@rcoh rcoh requested review from a team as code owners November 9, 2023 15:19
Copy link

github-actions bot commented Nov 9, 2023

A new generated diff is ready to view.

A new doc preview is ready to view.

Copy link

github-actions bot commented Nov 9, 2023

A new generated diff is ready to view.

A new doc preview is ready to view.

Copy link
Collaborator

@jdisanti jdisanti left a 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.
Copy link
Collaborator

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.

Comment on lines 26 to 30
<!-- 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
Copy link
Collaborator

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()`
Copy link
Collaborator

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.

Copy link
Collaborator Author

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.
Copy link
Collaborator

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`]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// 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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// 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");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

?

@jdisanti
Copy link
Collaborator

jdisanti commented Nov 9, 2023

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.

@rcoh rcoh mentioned this pull request Nov 13, 2023
3 tasks
@rcoh rcoh requested review from a team as code owners November 13, 2023 18:48
Copy link
Contributor

@ysaito1001 ysaito1001 left a 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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// Returns whether V1 behaviors are enabled.
/// Returns whether V2023_11_09 behaviors are enabled.

Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

Copy link

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())
Copy link
Collaborator

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`.
Copy link
Collaborator

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@rcoh rcoh enabled auto-merge November 14, 2023 21:29
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

@rcoh rcoh added this pull request to the merge queue Nov 14, 2023
Merged via the queue into main with commit 446326c Nov 14, 2023
40 of 41 checks passed
@rcoh rcoh deleted the behavior-major-versions branch November 14, 2023 22:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants