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 user agent #79

Merged
merged 20 commits into from
Dec 10, 2024
Merged

Add user agent #79

merged 20 commits into from
Dec 10, 2024

Conversation

TingDaoK
Copy link
Contributor

@TingDaoK TingDaoK commented Dec 4, 2024

Issue #, if available:

Description of changes:

  • Add an interceptor when we load the config to add the transfer manager metric for user agent
  • Add a framework metadata for the transfer manager config and pass it down to the sdk s3 client as the framework name in the user agent.
  • Only added for the ConfigLoader, we can decide what to do when user pass in their own client via config directly later.

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

@TingDaoK TingDaoK marked this pull request as ready for review December 4, 2024 21:26
@TingDaoK TingDaoK requested a review from a team as a code owner December 4, 2024 21:26
aws-s3-transfer-manager/examples/cp.rs Outdated Show resolved Hide resolved
aws-s3-transfer-manager/src/config/loader.rs Outdated Show resolved Hide resolved
@@ -278,6 +281,7 @@ async fn main() -> Result<(), BoxError> {
tracing_subscriber::fmt()
.with_env_filter(tracing_subscriber::EnvFilter::from_default_env())
.with_thread_ids(true)
.with_ansi(false) // Disable ANSI colors
Copy link
Contributor

Choose a reason for hiding this comment

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

question: why?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

with the ansi color, it's unreadable from pure text. I think it will be easier to read and parse.

@@ -43,6 +46,11 @@ impl Config {
&self.concurrency
}

/// Returns the name of the app that is using the transfer manager, if it was provided.
pub fn app_name(&self) -> Option<&AppName> {
Copy link
Contributor

Choose a reason for hiding this comment

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

fix: I don't think we want to expose app name. (1) we allow taking an S3 client (today anyway) that can already have app name configured, (2) I don't think this is what mountpoint will be looking for out of a UA header.

Is there something I'm missing here about why we are exposing this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From my reading of the sdk, the app name is just the string for the SDK to add in the user agent with some format check.

  1. I think if we take the s3 client and want to respect the setting from transfer manager, we will be adding the user agent setting from transfer manager to the passed in client as the app name.

  2. what do you think mountpoint will be looking for?
    I assume they just want a string, and I thought the app name is the wrap of string for SDK to be provided in the user agent.

Copy link
Contributor

Choose a reason for hiding this comment

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

From my reading of the sdk, the app name is just the string for the SDK to add in the user agent with some format check.

App name (appId) comes from the UA SEP. It's meant for end user applications (though I've yet to see someone use it 🤷‍♂️ in any SDK). Mountpoint could go through that but they are more like framework metadata.

I think if we take the s3 client and want to respect the setting from transfer manager, we will be adding the user agent setting from transfer manager to the passed in client as the app name.

The issue is the user could have set app name on the client. I think maybe we just leave this off for now and gather requirements from mountpoint to guide us. I think this is their user agent implementation though. From the looks of it we capture a lot of the md/* fields they are gathering I think so maybe they just need lib/mountpoint-s3-client#<version>.

Copy link
Contributor Author

@TingDaoK TingDaoK Dec 5, 2024

Choose a reason for hiding this comment

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

the framework metadata is supposed to be used as frameworks owned by the SDKs.

For frameworks owned by the SDKs, framework metadata MUST be included in the header following this format: "lib" / name ["#" version]. Additional metadata MAY be appended.

It seems to be an implementation detail for SDKs to me. And mountpoint is more like the application user, but yeah, they are more like a framework for the end user?
I guess we can chat with them and see what are they expecting?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah we run into this in other places. I think the SEP is worded poorly here. e.g. Amplify isn't owned by us but they need the same ability with the Kotlin SDK to tack on their UA info (which they utilize framework metadata IIRC).

aws-s3-transfer-manager/src/config/loader.rs Outdated Show resolved Hide resolved
aws-s3-transfer-manager/src/config/loader.rs Outdated Show resolved Hide resolved
aws-s3-transfer-manager/src/config/loader.rs Outdated Show resolved Hide resolved
@TingDaoK TingDaoK marked this pull request as draft December 5, 2024 23:49
aws-s3-transfer-manager/examples/cp.rs Outdated Show resolved Hide resolved
aws-s3-transfer-manager/src/config.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@aajtodd aajtodd left a comment

Choose a reason for hiding this comment

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

Fix and ship

aws-s3-transfer-manager/external-types.toml Outdated Show resolved Hide resolved
@@ -43,6 +46,12 @@ impl Config {
&self.concurrency
}

#[doc(hidden)]
Copy link
Contributor

Choose a reason for hiding this comment

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

style: Put the attributes first with doc comments above it (same elswewhere)

e.g.

/// Returns the framework metadata setting when using transfer manager
#[doc(hidden)]
pub fn framework_metadata(&self) -> Option<&FrameworkMetadata> { ... }

This goes for any attributes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I actually saw that in rust-sdk we put the attributes above the comments. https://github.com/awslabs/aws-sdk-rust/blob/main/sdk/aws-runtime/src/user_agent.rs#L172-L191

what kind of style rules we have? Are we put multiple attributes above comments?

@TingDaoK TingDaoK marked this pull request as ready for review December 9, 2024 22:04
@TingDaoK TingDaoK merged commit d18bc7a into main Dec 10, 2024
14 checks passed
@TingDaoK TingDaoK deleted the add-user-agent branch December 10, 2024 21:37
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.

4 participants