Package name and version
azure-appconfiguration 1.7.1
Describe the bug
When calling set_configuration_setting and passing an explicit etag keyword argument together with a ConfigurationSetting object that already has its own .etag attribute set (e.g. from a previous get_configuration_setting call), the explicitly-passed etag keyword argument appears to be silently ignored. The request seems to use the ConfigurationSetting object's own etag instead of the one I explicitly passed in.
Expected behavior
Per the docstring: "Will use the value from param configuration_setting if not set" -- meaning the explicit etag keyword argument should take priority when provided, and only fall back to configuration_setting.etag when the keyword argument is not given.
Actual behavior
The explicitly-passed etag keyword argument is not used whenever configuration_setting.etag is already set to a truthy value, causing unexpected ResourceModifiedError / stale-etag failures in optimistic-concurrency workflows where callers intentionally want to override the etag check.
Reproduction Steps
from azure.appconfiguration import AzureAppConfigurationClient, ConfigurationSetting
from azure.core import MatchConditions
client = AzureAppConfigurationClient.from_connection_string(conn_str)
existing = client.get_configuration_setting(key="MyKey")
# existing.etag is now set to some value, e.g. "abc123"
# I explicitly want to force using a DIFFERENT etag value for the match condition
updated = ConfigurationSetting(key="MyKey", value="new value", etag=existing.etag)
result = client.set_configuration_setting(
updated,
match_condition=MatchConditions.IfNotModified,
etag="some-other-etag-i-want-to-check-against",
)
# Expected: request uses etag="some-other-etag-i-want-to-check-against"
# Actual: request uses updated.etag instead, silently ignoring my explicit etag kwarg
Environment
No response
Package name and version
azure-appconfiguration 1.7.1
Describe the bug
When calling
set_configuration_settingand passing an explicitetagkeyword argument together with aConfigurationSettingobject that already has its own.etagattribute set (e.g. from a previousget_configuration_settingcall), the explicitly-passedetagkeyword argument appears to be silently ignored. The request seems to use theConfigurationSettingobject's own etag instead of the one I explicitly passed in.Expected behavior
Per the docstring: "Will use the value from param configuration_setting if not set" -- meaning the explicit
etagkeyword argument should take priority when provided, and only fall back toconfiguration_setting.etagwhen the keyword argument is not given.Actual behavior
The explicitly-passed
etagkeyword argument is not used wheneverconfiguration_setting.etagis already set to a truthy value, causing unexpectedResourceModifiedError/ stale-etag failures in optimistic-concurrency workflows where callers intentionally want to override the etag check.Reproduction Steps
Environment
No response