Disclaimer: The Issue and PR were created using Codex gpt-5.6-sol xhigh.
Problem
AWS JSON 1.0/1.1 service errors can contain modeled response members in addition to a message. The SDK currently identifies the correct modeled error variant but does not expose those additional members to callers.
A concrete example is DynamoDB conditional writes. DynamoDB supports ReturnValuesOnConditionCheckFailure=ALL_OLD, which allows the item responsible for a failed condition to be returned in ConditionalCheckFailedException. This is useful for optimistic-concurrency and conflict-resolution flows that need to inspect a stored value or hash.
The generated SDK already accepts the request option:
.return_values_on_condition_check_failure = .all_old
The pinned DynamoDB model also defines ConditionalCheckFailedException.Item as an AttributeMap.
Reproduction
- Insert an item containing a partition key, sort key, and another value such as a stored hash.
- Issue a conditional
PutItem that fails its condition.
- Set
.return_values_on_condition_check_failure = .all_old.
- Pass a
ServiceError diagnostic and inspect the .conditional_check_failed_exception variant.
Expected behavior
The modeled diagnostic should expose the returned old item, allowing callers to read its keys and stored values:
switch (diagnostic.kind) {
.conditional_check_failed_exception => |failure| {
const old_item = failure.item;
},
else => {},
}
Actual behavior
The request returns error.ServiceError and the diagnostic contains the correct .conditional_check_failed_exception variant, but the generated exception type exposes only normalized message and synthetic request_id fields.
The service response body contains the old item, but it is discarded before the diagnostic is returned. Consequently, callers cannot access the item or its stored hash.
ReturnValues=ALL_OLD is not a substitute because it applies to successful writes. Conditional failures require ReturnValuesOnConditionCheckFailure.
Impact
This is not limited to DynamoDB. Modeled exception members beyond message and request_id are unavailable across AWS JSON 1.0/1.1 services. That includes other structured diagnostic data such as cancellation and throttling details, even when those fields are present in the pinned Smithy models and returned by the service.
Disclaimer: The Issue and PR were created using Codex gpt-5.6-sol xhigh.
Problem
AWS JSON 1.0/1.1 service errors can contain modeled response members in addition to a message. The SDK currently identifies the correct modeled error variant but does not expose those additional members to callers.
A concrete example is DynamoDB conditional writes. DynamoDB supports
ReturnValuesOnConditionCheckFailure=ALL_OLD, which allows the item responsible for a failed condition to be returned inConditionalCheckFailedException. This is useful for optimistic-concurrency and conflict-resolution flows that need to inspect a stored value or hash.The generated SDK already accepts the request option:
The pinned DynamoDB model also defines
ConditionalCheckFailedException.Itemas anAttributeMap.Reproduction
PutItemthat fails its condition..return_values_on_condition_check_failure = .all_old.ServiceErrordiagnostic and inspect the.conditional_check_failed_exceptionvariant.Expected behavior
The modeled diagnostic should expose the returned old item, allowing callers to read its keys and stored values:
Actual behavior
The request returns
error.ServiceErrorand the diagnostic contains the correct.conditional_check_failed_exceptionvariant, but the generated exception type exposes only normalizedmessageand syntheticrequest_idfields.The service response body contains the old item, but it is discarded before the diagnostic is returned. Consequently, callers cannot access the item or its stored hash.
ReturnValues=ALL_OLDis not a substitute because it applies to successful writes. Conditional failures requireReturnValuesOnConditionCheckFailure.Impact
This is not limited to DynamoDB. Modeled exception members beyond
messageandrequest_idare unavailable across AWS JSON 1.0/1.1 services. That includes other structured diagnostic data such as cancellation and throttling details, even when those fields are present in the pinned Smithy models and returned by the service.