Provide client config property for region provider

[ianbotsf]

Describe the feature

Currently, SDK client config has a region property which is a non-defered static string. Internally, the SDK uses RegionProvider and DefaultRegionProviderChain to lazily infer the region when one is not explicitly provided by the caller. This complicates dynamic region selection for callers who use their own configuration lookup mechanisms or want to use custom provider chains.

Is your feature request related to a problem?

The lack of a regionProvider property complicates dynamic region selection for callers who use their own configuration lookup mechanisms or want to use custom provider chains. Users must manage their own chain independently and then call getRegion() to pass to the client's region property:

val myRegionProvider = RegionProviderChain(src1, src2, src3, ...)

val s3 = S3Client.fromEnvironment {
    region = myRegionProvider.getRegion()
}

Proposed Solution

Expose a regionProvider client config property alongside region. When set, it should replace the default region provider chain used when a static region is not specified:

val myRegionProvider = RegionProviderChain(src1, src2, src3, ...)

val s3 = S3Client.fromEnvironment {
    regionProvider = myRegionProvider 
}

If a static region is specified, the value of regionProvider will not be used:

val myRegionProvider = ...

val s3 = S3Client.fromEnvironment {
    regionProvider = myRegionProvider // Ignored since `region` is also set
    region = "moon-east-1"
}

Describe alternative solutions or features you've considered

The existing region property presently allows using providers indirectly but it's not very ergonomic and differs from how credentials are resolved.

Acknowledge

• I may be able to implement this feature request

AWS SDK for Kotlin version

1.3.93

Platform (JVM/JS/Native)

(any)

Operating system and version

(any)

[cloudshiftchris]

Is this the right thing to do?

   regionProvider = myRegionProvider // Ignored since `region` is also set
    region = "moon-east-1"

Alternatively this could error out - but that may be surprising in more complicated cases where the configuration is composed (not always two lines of code together), and perhaps hard to resolve.

Also an option is to flip the resolution, on the premise that a RegionProvider may be more relevant than static configuration (but not always...).

Are there other *Providers in the SDK that have perhaps already addressed this?

I don't have a strong opinion or specific requirements here - whatever you decide will be fine, so long as the "conflict resolution" behaviour is clearly documented.

[ianbotsf]

My instinct is to bias towards the most specific option (i.e., region) rather than a less specific option (i.e., regionProvider). This matches the current behavior of endpointUrl and endpointProvider—endpointUrl wins if both are set. We'll discuss internally in more depth to verify that's the best approach but if you have further thoughts about one approach vs the other we'd love to take those into account. 🙂 And of course whichever option we select, we'll need to update/clarify our documentation.

If we do stick with the proposed region > regionProvider approach, it might be sensible to log a warning when both are set. This would probably apply to endpointUrl > endpointProvider too.

[cloudshiftchris]

Agree on the "most specific" approach; good to know that endpoint* already has that behaviour.

Like the idea of logging a warning - silently ignoring things is a 💣 that we'd all prefer to avoid!

Possibly over engineering - add a "configuration resolution mode" or some such settings, defaults to Warn, could also be Error. I'd expect this would get rarely used, though, perhaps not worth the effort.

[ianbotsf]

Resolved by smithy-lang/smithy-kotlin#1210 and #1488.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[ianbotsf]

@cloudshiftchris support for region provider configuration will be available in the SDK starting in minor version v1.5, scheduled for release later this year. We wanted to release it directly to main but we had to restructure some of the region-related classes in a manner that is backwards-incompatible so we're delaying release until the next minor version of the SDK.

[cloudshiftchris]

Awesome, thanks @ianbotsf