DynamoDB ExecuteStatementOutput.items order is non-deterministic

[brianheineman]

Describe the bug

The aws-sdk-dynamodb::Client.execute_statement() function allows a SQL query to be executed (e.g. SELECT id, name FROM users) where the caller can specify columns/attributes with an explicit order. The ExecuteStatementOutput.items specifies the results using a HashMap<String, AttributeValue> which does not guarantee the order of the columns. When the SQL is based on user input, they expect the columns to be returned in the order they specify (e.g. id, name), and not in an arbitrary order (e.g. name, id).

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

Attributes returned in ExecuteStatementOutput.items should be in the order specified by the user when explicitly specified, or the table definition when * is used.

Current Behavior

Attribute are returned in a non-deterministic order.

Reproduction Steps

Test program that reproduces the issue: dynamodb.zip

Possible Solution

I have only looked at the interfaces for the API. Perhaps a place to start is to define ExecuteStatementOutput.items to be IndexMap<String, AttributeValue>.

Additional Information/Context

No response

Version

├── aws-config v1.6.1
│   ├── aws-credential-types v1.2.2
│   │   ├── aws-smithy-async v1.2.5
│   │   ├── aws-smithy-runtime-api v1.7.4
│   │   │   ├── aws-smithy-async v1.2.5 (*)
│   │   │   ├── aws-smithy-types v1.3.0
│   │   ├── aws-smithy-types v1.3.0 (*)
│   ├── aws-runtime v1.5.6
│   │   ├── aws-credential-types v1.2.2 (*)
│   │   ├── aws-sigv4 v1.3.0
│   │   │   ├── aws-credential-types v1.2.2 (*)
│   │   │   ├── aws-smithy-http v0.62.0
│   │   │   │   ├── aws-smithy-runtime-api v1.7.4 (*)
│   │   │   │   ├── aws-smithy-types v1.3.0 (*)
│   │   │   ├── aws-smithy-runtime-api v1.7.4 (*)
│   │   │   ├── aws-smithy-types v1.3.0 (*)
│   │   ├── aws-smithy-async v1.2.5 (*)
│   │   ├── aws-smithy-http v0.62.0 (*)
│   │   ├── aws-smithy-runtime v1.8.1
│   │   │   ├── aws-smithy-async v1.2.5 (*)
│   │   │   ├── aws-smithy-http v0.62.0 (*)
│   │   │   ├── aws-smithy-http-client v1.0.1
│   │   │   │   ├── aws-smithy-async v1.2.5 (*)
│   │   │   │   ├── aws-smithy-runtime-api v1.7.4 (*)
│   │   │   │   ├── aws-smithy-types v1.3.0 (*)
│   │   │   │   │   │   ├── aws-lc-rs v1.12.6
│   │   │   │   │   │   │   ├── aws-lc-sys v0.27.1
│   │   │   │   │   │   │   ├── aws-lc-rs v1.12.6 (*)
│   │   │   ├── aws-smithy-observability v0.1.2
│   │   │   │   ├── aws-smithy-runtime-api v1.7.4 (*)
│   │   │   ├── aws-smithy-runtime-api v1.7.4 (*)
│   │   │   ├── aws-smithy-types v1.3.0 (*)
│   │   ├── aws-smithy-runtime-api v1.7.4 (*)
│   │   ├── aws-smithy-types v1.3.0 (*)
│   │   ├── aws-types v1.3.6
│   │   │   ├── aws-credential-types v1.2.2 (*)
│   │   │   ├── aws-smithy-async v1.2.5 (*)
│   │   │   ├── aws-smithy-runtime-api v1.7.4 (*)
│   │   │   ├── aws-smithy-types v1.3.0 (*)
│   ├── aws-sdk-sso v1.63.0
│   │   ├── aws-credential-types v1.2.2 (*)
│   │   ├── aws-runtime v1.5.6 (*)
│   │   ├── aws-smithy-async v1.2.5 (*)
│   │   ├── aws-smithy-http v0.62.0 (*)
│   │   ├── aws-smithy-json v0.61.3
│   │   │   └── aws-smithy-types v1.3.0 (*)
│   │   ├── aws-smithy-runtime v1.8.1 (*)
│   │   ├── aws-smithy-runtime-api v1.7.4 (*)
│   │   ├── aws-smithy-types v1.3.0 (*)
│   │   ├── aws-types v1.3.6 (*)
│   ├── aws-sdk-ssooidc v1.64.0
│   │   ├── aws-credential-types v1.2.2 (*)
│   │   ├── aws-runtime v1.5.6 (*)
│   │   ├── aws-smithy-async v1.2.5 (*)
│   │   ├── aws-smithy-http v0.62.0 (*)
│   │   ├── aws-smithy-json v0.61.3 (*)
│   │   ├── aws-smithy-runtime v1.8.1 (*)
│   │   ├── aws-smithy-runtime-api v1.7.4 (*)
│   │   ├── aws-smithy-types v1.3.0 (*)
│   │   ├── aws-types v1.3.6 (*)
│   ├── aws-sdk-sts v1.64.0
│   │   ├── aws-credential-types v1.2.2 (*)
│   │   ├── aws-runtime v1.5.6 (*)
│   │   ├── aws-smithy-async v1.2.5 (*)
│   │   ├── aws-smithy-http v0.62.0 (*)
│   │   ├── aws-smithy-json v0.61.3 (*)
│   │   ├── aws-smithy-query v0.60.7
│   │   │   ├── aws-smithy-types v1.3.0 (*)
│   │   ├── aws-smithy-runtime v1.8.1 (*)
│   │   ├── aws-smithy-runtime-api v1.7.4 (*)
│   │   ├── aws-smithy-types v1.3.0 (*)
│   │   ├── aws-smithy-xml v0.60.9
│   │   ├── aws-types v1.3.6 (*)
│   ├── aws-smithy-async v1.2.5 (*)
│   ├── aws-smithy-http v0.62.0 (*)
│   ├── aws-smithy-json v0.61.3 (*)
│   ├── aws-smithy-runtime v1.8.1 (*)
│   ├── aws-smithy-runtime-api v1.7.4 (*)
│   ├── aws-smithy-types v1.3.0 (*)
│   ├── aws-types v1.3.6 (*)
├── aws-credential-types v1.2.2 (*)
├── aws-sdk-dynamodb v1.70.0
│   ├── aws-credential-types v1.2.2 (*)
│   ├── aws-runtime v1.5.6 (*)
│   ├── aws-smithy-async v1.2.5 (*)
│   ├── aws-smithy-http v0.62.0 (*)
│   ├── aws-smithy-json v0.61.3 (*)
│   ├── aws-smithy-runtime v1.8.1 (*)
│   ├── aws-smithy-runtime-api v1.7.4 (*)
│   ├── aws-smithy-types v1.3.0 (*)
│   ├── aws-types v1.3.6 (*)

Environment details (OS name and version, etc.)

MacOS Sequoia 15.3.2

Logs

No response

[ysaito1001]

Thank you for bringing this to our attention. While what you described makes sense, fixing the underlying map type isn't quite as trivial for two reasons.

First, the use of the HashMap type originates from the service model of DynamoDB (where ItemList is defined here and AttributeMap is defined here). "type": "map" in AttributeMap is what generates HashMap at the end of the day.

Second, modifying the type of a map from HashMap to IndexMap is a breaking change because the field items is exposed as pub within ExecuteStatementOutput.

[brianheineman]

@ysaito1001 thank you for the quick reply. Is there some alternative API that could return the column order if the current interface cannot be updated?