The `configure list` command shows the wrong effective value and source for `region`.
Describe the bug
When there is region key in the ~/.aws/credentials file, as per AWS Documentation it has higher precedence then the one in ~/.aws/config.
So when AWS_REGION env. var. is not set and we have regions keys in both files, the one in the credential file become the effective region when --region is not set in the CLI.
However printing out the aws configure list still shows the source as config file and the value is set to what is in the config file. While the value is indeed matching with the one in the config file, but this is NOT the effective value used.
This is very confusing and at this point we don't have a mean to show what is the actual effective value used.
Regression Issue
- [ ] Select this option if this issue appears to be a regression.
Expected Behavior
It should shows that the source is from credential file and the value set in that file.
Current Behavior
It shows that the source is from config file and the value set in that file.
Reproduction Steps
- Have
regionkeys on the same profile in both config & shared credential files. - Unset
AWS_REGIONenv. var. - Execute
aws configure list.
Possible Solution
No response
Additional Information/Context
No response
CLI version used
aws-cli/2.32.1 Python/3.13.9 Linux/6.12.0-153.el10.x86_64 exe/x86_64.rhel.10
Environment details (OS name and version, etc.)
UBI (RedHat) 10 Container.
Hi @etirta, thanks for pointing this out. I attempted to reproduce this behavior, and got something slightly different from what you described.
My config looks like this.
[default]
region = us-west-2
output = json
retry_mode = standard
max_attempts = 5
My credentials file looks like this.
[default]
aws_access_key_id = redacted
aws_secret_access_key = redacted
region = us-east-1
When I run aws configure list, it correctly shows the region being used as us-east-1, but marks it as coming from the config file, rather than the credentials file.
region : us-east-1 : config-file : ~/.aws/config
Either way this isn't correct behavior, but could you confirm that this is different from what you're seeing?