Scan request validation gaps: empty ScanFilter in the parameter mix, empty AttributesToGet, legacy and ExclusiveStartKey numbers, ExpressionAttributeValues nesting depth #564

Observed on the service

Measured against DynamoDB (us-east-1) on 2026-10-25 at 10:38 and 10:55 UTC, each request sent twice, raw signed HTTP Scan on an existing table of 29 items.

1. An empty ScanFilter counts as present for the expression and non-expression parameter mix. ScanFilter: {} with FilterExpression: "a = :n" answers ValidationException: Can not use both expression and non-expression parameters in the same request: Non-expression parameters: {ScanFilter} Expression parameters: {FilterExpression}. ScanFilter: {} alone is accepted (200, Count 29); ScanFilter: {} with an unused {"N": "bob"} answers the number text.
2. An empty AttributesToGet is refused by a length constraint ahead of the number check. AttributesToGet: [] alone, with a FilterExpression, or with a FilterExpression and a {"N": "bob"} value, answers 1 validation error detected: Value at 'AttributesToGet' failed to satisfy constraint: Member must have length greater than or equal to 1.
3. A malformed N in a legacy ScanFilter AttributeValueList answers The parameter cannot be converted to a numeric value: bob.
4. A malformed N in ExclusiveStartKey (with a valid filter) answers The parameter cannot be converted to a numeric value: bob.
5. ExpressionAttributeValues nesting depth. An L nested 32 or deeper with a valid N at the bottom, unused, answers Nesting Levels have exceeded supported limits: Attributes in the item have nested levels beyond supported limit (depths 32, 33, 40 and 60 measured); 31 levels answers the unused-value text. With {"N": "bob"} at the bottom, depths 31 to 60 and an M at 32 answer the number text: the number check runs before the nesting check. At 100 levels the service answers ExpressionAttributeValues contains invalid value: Nesting Levels have exceeded supported limits: Attributes in the item have nested levels beyond supported limit for key :d.

Observed on ExtendDB

At the head of the Scan number check branch, and on main except where main has no number check on Scan (item 2):

1. ScanFilter: {} with a FilterExpression is accepted (200, the filter runs).
2. AttributesToGet: [] is accepted (200), with or without a ProjectionExpression or a number fault; with a {"N": "bob"} value the number text is reported instead of the length constraint.
3. ScanFilter with {"N": "bob"} in an AttributeValueList is accepted (200, Count 0).
4. ExclusiveStartKey with {"N": "bob"} on an S key answers The provided starting key is invalid: The provided key element does not match the schema.
5. No nesting depth check on Scan or Query: a 32 level L with a valid number answers the unused-value text or scans; at 100 levels the JSON parser's limit answers SerializationException: ... recursion limit exceeded. PutItem, UpdateItem and DeleteItem call validate_attribute_values_nesting_depth; scan.rs and query.rs do not.

Proposed change

In the Scan request-time checks: count an object ScanFilter as present whether or not it is empty; refuse AttributesToGet: [] with the length constraint text, ahead of the number check; run the number check over the legacy AttributeValueList values and the ExclusiveStartKey values; and call the nesting depth check on ExpressionAttributeValues after the number check, with the bare text for depths the parser accepts. The same AttributesToGet and QueryFilter questions apply to Query and should be measured there before they are encoded.