Add a config property descriptor along with a custom resolver and validators by ubaskota · Pull Request #642 · smithy-lang/smithy-python

ubaskota · 2026-02-24T05:29:55Z

Issue #, if available:

This PR adds a ConfigProperty descriptor that serves as the central instrument for configuration resolution. The descriptor is responsible for resolving config values from sources, applying custom resolvers for complex resolutions, validating values, caching them, and facilitating value updates.

The ConfigProperty descriptor implements the Python descriptor protocol to provide:

Lazy resolution
Validation
Caching
Custom resolver
Source tracking

Initial config variables:

region - demonstrates simple resolution
retry_strategy - demonstrates complex resolution (aggregates retry_mode and max_attempts)

These two variables ensure that the design handles both simple and complex resolution.

Tests

Verified that the unit tests for config property, validators and custom revolvers pass successfully.

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

…idators

packages/smithy-aws-core/src/smithy_aws_core/config/custom_resolvers.py

packages/smithy-aws-core/src/smithy_aws_core/config/validators.py

packages/smithy-aws-core/src/smithy_aws_core/config/custom_resolvers.py

packages/smithy-aws-core/src/smithy_aws_core/config/validators.py

packages/smithy-aws-core/tests/unit/config/test_custom_resolver.py

packages/smithy-core/src/smithy_core/config/property.py

packages/smithy-aws-core/src/smithy_aws_core/config/validators.py

packages/smithy-aws-core/src/smithy_aws_core/config/custom_resolvers.py

packages/smithy-core/src/smithy_core/config/property.py

packages/smithy-core/tests/unit/config/test_property.py

SamRemis · 2026-02-26T14:02:33Z

packages/smithy-aws-core/src/smithy_aws_core/config/custom_resolvers.py

+    # Get max_attempts
+    max_attempts, attempts_source = resolver.get("max_attempts")
+
+    if retry_mode is None or max_attempts is None:


This is ignoring one of these values if both aren't set. It's valid for a customer to only set retry_mode and not max_attempts and expect that to be respected.

Think of a scenario where we need to resolve retry_strategy, but the resolver only finds retry_mode in the sources without max_attempts. Should we mix the resolved retry_mode with a default max_attempts value? This approach doesn't make sense because when a client needs to resolve retry_strategy, it will have a default retry_strategy value configured. To me it doesn’t make sense to mix a partially resolved strategy with default components. Instead, if either component (retry_mode or max_attempts) is missing, we should use the complete default retry_strategy.

Not sure I agree with that; I should be able to set either mode OR strategy and have that be reflected. That's how this input works today - you can set only one of the two inputs on the RetryStrategyOptions object.

As a user, I can trust the SDK to pick the right number of max attempts, but realize that I'm likely to get throttled so I'd want to choose adaptive retry mode. If I only set AWS_RETRY_MODE=adaptive in the environment, that needs to be respected.

While I don't think there's a scenario where it would make sense to ignore the user input here, even if there were, we would at least need to raise an error or warning to tell the customer that we are ignoring their input. This would ignore it silently.

packages/smithy-aws-core/src/smithy_aws_core/config/validators.py

SamRemis · 2026-02-26T21:52:29Z

packages/smithy-core/src/smithy_core/config/property.py

+        self,
+        key: str,
+        validator: Callable[[Any, str | None], Any] | None = None,
+        resolver_func: Callable[[ConfigResolver], tuple[Any, str | None]] | None = None,


As a follow-up, I'd like to talk about getting the source to be an enum instead of a string

SamRemis · 2026-02-27T14:33:38Z

packages/smithy-aws-core/src/smithy_aws_core/config/custom_resolvers.py

+    # Get max_attempts
+    max_attempts, attempts_source = resolver.get("max_attempts")
+
+    if retry_mode is None or max_attempts is None:


Not sure I agree with that; I should be able to set either mode OR strategy and have that be reflected. That's how this input works today - you can set only one of the two inputs on the RetryStrategyOptions object.

As a user, I can trust the SDK to pick the right number of max attempts, but realize that I'm likely to get throttled so I'd want to choose adaptive retry mode. If I only set AWS_RETRY_MODE=adaptive in the environment, that needs to be respected.

While I don't think there's a scenario where it would make sense to ignore the user input here, even if there were, we would at least need to raise an error or warning to tell the customer that we are ignoring their input. This would ignore it silently.

SamRemis · 2026-02-27T21:20:55Z

packages/smithy-aws-core/src/smithy_aws_core/config/custom_resolvers.py

+        max_attempts = validate_max_attempts(max_attempts, attempts_source)
+
+    options = RetryStrategyOptions(
+        retry_mode=retry_mode or "standard",  # type: ignore


Suggested change

retry_mode=retry_mode or "standard", # type: ignore

retry_mode=retry_mode

SamRemis · 2026-02-27T21:25:27Z

packages/smithy-aws-core/src/smithy_aws_core/config/validators.py

+        super().__init__(msg)
+
+
+def validate_host_label(host_label: Any, source: str | None = None) -> str:


A host label has to be a string, right?

Suggested change

def validate_host_label(host_label: Any, source: str | None = None) -> str:

def validate_host_label(host_label: str, source: str | None = None) -> str:

SamRemis · 2026-02-28T00:08:48Z

packages/smithy-core/src/smithy_core/config/property.py

+        if self.resolver_func:
+            value, source = self.resolver_func(obj._resolver)
+        else:
+            value, source = obj._resolver.get(self.key)


As another follow up, we should expose each source from the resolver so they can be called directly, for example for use in environment only configs like the bedrock token

SamRemis · 2026-02-28T00:22:22Z

packages/smithy-core/src/smithy_core/config/property.py

+    def __get__(self, obj: Any, objtype: type | None = None) -> Any:
+        """Get the config value with lazy resolution and caching.
+
+        On first access, the property checks if the value is already cached. If not, it resolves


Third follow up - we should have some caching on the resolver as well and make sure they share the config resolver.

Add a config property descriptor along with a custom resolver and val…

bdccfa3

…idators

ubaskota requested a review from a team as a code owner February 24, 2026 05:29

Remove a decorator that handles None value and update the tests

4eb1b76

SamRemis reviewed Feb 25, 2026

View reviewed changes

alexgromero reviewed Feb 25, 2026

View reviewed changes

Address reviews and comments

09f2546

SamRemis reviewed Feb 26, 2026

View reviewed changes

Address reviews

3550baf

SamRemis reviewed Feb 27, 2026

View reviewed changes

ubaskota added 2 commits February 27, 2026 15:04

Address reviews

b44493a

Fix and add tests

d346728

SamRemis reviewed Feb 27, 2026

View reviewed changes

Address reviews

1a21a17

SamRemis approved these changes Feb 28, 2026

View reviewed changes

SamRemis reviewed Feb 28, 2026

View reviewed changes

ubaskota merged commit eb22199 into smithy-lang:config_resolution_main Feb 28, 2026
4 checks passed

	retry_mode=retry_mode or "standard", # type: ignore
	retry_mode=retry_mode

		super().__init__(msg)


		def validate_host_label(host_label: Any, source: str \| None = None) -> str:

	def validate_host_label(host_label: Any, source: str \| None = None) -> str:
	def validate_host_label(host_label: str, source: str \| None = None) -> str:

Conversation

ubaskota commented Feb 24, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants