-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
AWSCredentialsProviderChain should return Exceptions from providers, not just the combined message #3160
Comments
Hi @ivankhoosty Java SDK 1.x is in Maintenance Mode, it'll only get security updates and critical bug fixes. We don't have plans to change the logging.
This is exactly the instruction we give when troubleshooting credential issues: replace the default chain for the credential provider you expect to be used, and check the logs. |
@debora-ito I have just noticed I pasted the links to sdk 1.x by mistake, I had both open to compare the code, and 2.x classes code is the same. |
In 2.x if you set the log level to DEBUG you'll see the stacktraces of the individual credential provider calls in the chain:
|
That’s not what happens because of the stage in spring boot loader. I will prepare a sample spring boot app to show you the issue |
@ivankhoosty perhaps this issue should be moved to https://github.com/awspring/spring-cloud-aws project? |
@maciejwalkowiak I dont know what you can do when Spring is not logging DeferredLog during boostrap failure. I think AwsCredentialsProviderChain appending error messages from various credentialsProviders to use it as the SdkClientException message is not consistent, they should be chaining the actual exceptions into the cause of SdkClientException as well. @debora-ito makes a comment above "This is exactly the instruction we give when troubleshooting credential issues: replace the default chain for the credential provider you expect to be used, and check the logs." - this would not be necessary at all if exceptions from credentialsProviders were preserved and stored in SdkClientException |
"... replace the default chain for the credential provider you expect to be used, and check the logs" is the instruction when using Java SDK 1.x. In Java SDK 2.x you can see the full stacktraces when you use DEBUG level logging. Maybe this is a configuration that spring-cloud-aws needs to expose? We wouldn't like to change to print those at regular level as they are pretty verbose and will be printed with every client that uses the default chain. |
Upcoming End-of-Support
Describe the bug
If an error occurs when fetching secrets from the secretsmanager during Spring startup, no logs are available as described in awspring/spring-cloud-aws#165 . The only information that is available to diagnose what went wrong with DefaultCredentialsProvider is the exception stacktrace/message generated on https://github.com/aws/aws-sdk-java/blob/df2ce8afe8f1c1ecebc110b9c451de4c904250fc/aws-java-sdk-core/src/main/java/com/amazonaws/auth/AWSCredentialsProviderChain.java#L142C38-L142C100
In my situation, ContainerCredentialsProvider provided message "Failed to load credentials from metadata service.", but the original (proxy/network/etc related) cause Exception was not visible in the logs, as
aws-sdk-java/aws-java-sdk-core/src/main/java/com/amazonaws/auth/AWSCredentialsProviderChain.java
Line 132 in df2ce8a
The workaround was to replace DefaultCredentialsProvider with ContainerCredentialsProvider to see the cause Exception and fix the issue.
@maciejwalkowiak
Regression Issue
Expected Behavior
I would want to see the exceptions that caused each provider to fail in the stacktrace of the
aws-sdk-java/aws-java-sdk-core/src/main/java/com/amazonaws/auth/AWSCredentialsProviderChain.java
Line 142 in df2ce8a
Current Behavior
only messages from the exceptions that caused each provider to fail are part of the exception generated on
aws-sdk-java/aws-java-sdk-core/src/main/java/com/amazonaws/auth/AWSCredentialsProviderChain.java
Line 142 in df2ce8a
Reproduction Steps
this is only reproducible if your app is fetching secrets via spring.config.import: aws-secretsmanager . Failures during this boostrap stage do not have any logs printed.
Possible Solution
Chain causes of failures of all providers and set as the cause for the exception thrown on line 142 ?
Additional Information/Context
No response
AWS Java SDK version used
2.28.28
JDK version used
21.0.1
Operating System and version
unix
The text was updated successfully, but these errors were encountered: