Bug description
The Spring AI documentation for Bedrock Converse allows us to set several configuration values, one of these is the AWS region we'd like to use when talking to Bedrock (spring.ai.bedrock.aws.region
).
First, when we setup the client we let it use the Amazon AWS SDK's logic to figure out the region. If this fails then we use the property's value and, if it's not set, we use our default value. I think this may be confusing to people using the library: the documentation is clear that if the spring.ai.bedrock.aws.region
property is set then it will be respected, if not then the region will be us-east-1
. In reality we'll use Amazon's logic first and, if that fails, only then will we set the region to the property value or the expected default. You'll find the following in the code for the BedrockProxyChatModel
class.
private Builder() {
try {
this.region = DefaultAwsRegionProviderChain.builder().build().getRegion();
}
catch (SdkClientException e) {
logger.warn("Failed to load region from DefaultAwsRegionProviderChain, using US_EAST_1", e);
}
}
Note that we also log the entire stacktrace for the exception here, even though this exception will not halt the application. I think this logging of the stacktrace is confusing, I personally thought that it was preventing application startup at first glance.
Steps to reproduce
Neglect to set the AWS_REGION
environment variable for a project that uses the Bedrock Converse API. Depending on your environment you might see the stracktrace and yet the application will startup or you might find that instead of being configured to use the us-east-1
region it's using a region from a pre-existing AWS SSO login or even from data fetched from the EC2 metadata service.
Expected behavior
I expected a warning about the AWS region not being set and the us-east-1
region being used, per the documentation.
Recommendation
We should remove the logging of the stacktrace when the Amazon SDK fails to find a region. We know we're going to set it to our default and that this exception is (to some degree) expected. Instead log a warning (as we do) and move on.
I can see the benefit of using the AWS SDK's logic for configuring the client, in my opinion it makes sense to let the SDK configure itself and then only set values if we need to set them. When deploying code to the AWS Lambda Service, this allows this configuration to be handled entirely by Amazon.
That being said we should update the documentation to make this clear. Those who are new to the Amazon AWS SDK for Java may be surprised by this behavior. While educating developers on how the SDK is not our job we could hint that it's a little complicated.