[LeeroyHannigan]

Stacked on #399, whose per-path semantic walk this change uses. After #399 merges, retarget it to main.

An expression whose document path has more than 32 elements is now refused, as DynamoDB refuses it. Before, ExtendDB had no limit: a 33-element path was evaluated, and an UpdateItem ADD on one created the missing maps and stored the result.

What the service answers

Measured on 2026-10-26 at 02:26, 02:29, 03:38, 03:39, 04:21, 04:40, 04:41, 04:43, 05:13, 05:15, 05:20 and 05:40 UTC in us-east-1, each request twice with the same answer, apart from the case noted below.

• A path of more than 32 elements is refused with ValidationException Invalid <Kind>: The document path has too many nesting levels; nesting levels: <n>. Each attribute name and each list index counts as one element. It holds in UpdateExpression (every action, the value side of SET, if_not_exists, list_append), ConditionExpression (PutItem, UpdateItem, DeleteItem, TransactWriteItems), ProjectionExpression (GetItem, BatchGetItem, TransactGetItems, Query, Scan), FilterExpression (Query, Scan) and KeyConditionExpression. Counts up to 2,040 are reported exactly.
• The service checks each path's #name references and then its length, path by path in the order the paths appear. An undefined #name in an earlier path or inside the long path is reported instead; one in a later path is reported after the length. An undefined :value, an unused name or value and overlapping paths are reported after the length.
• A syntax error anywhere in the expression is reported first.
• Between expressions of one request, the FilterExpression is checked before the ProjectionExpression, and on UpdateItem the ConditionExpression before the UpdateExpression, as fix(expressions): validate in the service's order, with its messages #399 already orders them. Inside TransactWriteItems an Update item's UpdateExpression comes before its ConditionExpression.
• A KeyConditionExpression with a 33-element path answers the length; with 32 it answers KeyConditionExpressions cannot have conditions on nested attributes.
• Two other checks come before the length, and before much else:
  • The BETWEEN bounds check (both bounds placeholders, of different types or with the lower above the upper) is made at request time: on a missing key, after a false AND, and in a Query of an empty partition.
  • On PutItem, UpdateItem and DeleteItem, an ExpressionAttributeValue nested more than 32 levels is reported after an invalid number in the Item or the Key and after legacy and expression parameters used together, and before names or values without an expression, a syntax error, an undefined name, the condition, a missing table and the key. With an invalid number and a value nested too deep both in ExpressionAttributeValues, the service answers either error from one request to the next.

The change

• crates/core/src/expression/path_length.rs (new): the limit and the sentence.
• crates/core/src/expression/semantics/refs.rs: check_path_refs, which fix(expressions): validate in the service's order, with its messages #399's walk calls for every path of an update or condition expression in text order, checks the length after the path's names.
• crates/core/src/expression/projection.rs: resolve_paths checks each projection path's length after resolving its names.
• crates/core/src/expression/key_condition.rs: the length of every key condition path is checked before the nested-attribute refusal.
• crates/core/src/expression/evaluator.rs and semantics/condition_rules.rs: the BETWEEN bounds check moves into a function the semantic walk calls; the evaluator keeps calling it too. Without this move, a request with a long update path and a condition with bounds out of order answered the length error, where the service and fix(expressions): validate in the service's order, with its messages #399 answer the bounds error.
• crates/engine/src/update_item.rs and put_item.rs: the ExpressionAttributeValues nesting check moves earlier. On UpdateItem it runs right after the check for legacy and expression parameters used together; on PutItem right after the table name check, with the Item's numbers checked first. DeleteItem already runs it after the mixed-parameter check. Without this move, a long path beside a value nested too deep answered the length error.
• docs/dynamodb-limits.md: a row for the limit.

Where ExtendDB still answers differently

• Reserved words. ExtendDB checks them on the token stream before any path; the service checks them in the same walk, so SET <33 elements> = :s, status = :s answers the reserved word error on ExtendDB and the length on the service.
• Shapes ExtendDB's parsers refuse before any semantic check, where the service answers the length error: a KeyConditionExpression with OR, <>, a function, IN, NOT or a path as the value, and ADD with a path as its value. ExtendDB answers its own syntax messages there, with or without this change.
• In a KeyConditionExpression the length is checked in the parser, before fix(expressions): validate in the service's order, with its messages #399 checks the names, so #zz = :p AND <33> = :s with #zz undefined answers the length error, where the service answers the undefined name. fix(expressions): validate in the service's order, with its messages #399's head answers a different message for it as well.
• An invalid number in the Key of UpdateItem or DeleteItem is checked after the table lookup, so beside a value nested too deep it answers the nesting error on ExtendDB, where the service answers the number error. fix(expressions): validate in the service's order, with its messages #399's head answers a key schema error there.
• PutItem and DeleteItem with a value nested too deep and no ConditionExpression answer ExtendDB's values-without-expression error, where the service answers the nesting error; the check order there is unchanged from fix(expressions): validate in the service's order, with its messages #399's head.
• ExtendDB's syntax error wording, which differs from the service's Syntax error; token: ..., near: ... (fix(expression): operator cap, syntax error wording, PutItem map keys #558).

Tests

• crates/core/src/expression/path_length.rs: the limit, list indexes, the key condition order, the projection and update order against #name references. semantics/tests.rs: the BETWEEN bounds in the walk.
• tests/test_document_path_length.py: 53 dual-target wire tests from the measurements. The at-the-limit condition uses size() of the 32-element path, which the MongoDB condition pushdown does not handle, so the test does not depend on MongoDB: a condition on a nested map member fails when it holds #572.

Run locally against SQLite on 2026-10-26, with #399's head (4f4fc21) as the base:

• the new file at the head: 53 passed; on fix(expressions): validate in the service's order, with its messages #399's head: 33 failed, 20 passed.
• every request measured on the service for this work (12 probe runs) replayed against the head and fix(expressions): validate in the service's order, with its messages #399's head: no case where fix(expressions): validate in the service's order, with its messages #399's head matches the service and the head does not. Of the 334 cases, the head matches the service on 287 and fix(expressions): validate in the service's order, with its messages #399's head on 119, exactly or apart from the 1 validation error detected: prefix.
• every file under tests/ whose test names match expression, condition, projection, query, scan, update, transact, batch_get, reserved, nested, key_condition, put_item, delete_item, validation, between, number, legacy, expected or attribute_updates: 1,125 passed, 9 skipped at the head; on fix(expressions): validate in the service's order, with its messages #399's head the same tests pass apart from the new file's 33.
• tests/python tests whose names match expression, condition, projection, query, scan, update, transact, put or delete: 218 passed on both.
• cargo +1.97.0 fmt --all -- --check, cargo +1.97.0 clippy --all-targets -- -D warnings, cargo test --workspace --exclude extenddb-storage-cassandra on stable and on 1.88.0 (1,790 passed each), and cargo test -p extenddb-storage-cassandra --lib (61 passed). The 47-test version of the new file also passed on PostgreSQL and MongoDB.

CI runs the new file in run-integration, run-integration-sqlite, mongodb-pytest and cassandra-pytest.

Files

crates/core/src/expression/key_condition.rs (1,912 lines on #399's head) grows by 7 and projection.rs (693) by 4, the calls. The rest stays under 600 lines or shrinks; the check lives in the new path_length.rs.

Merging

This is based on #399's branch. After #399 merges, retarget it to main. Since #399's previous base, 9d13202, three main PRs changed files this change also changes: #511 key_condition.rs and expression/mod.rs, #543 docs/dynamodb-limits.md, and #429 key_condition.rs. This change's diff applies to #399 rebased onto main at f49c5f8. git range-diff 17b805da..90b673b8 1454cc93..8549bc02 shows the same diff for all four commits; in the first, the key_condition.rs hunk now sits in parse_clauses, and the mod.rs hunk follows #511's wider key_condition re-export.

git merge-tree --write-tree against the 11 open PRs that change crates/core/src/expression/, update_item.rs or put_item.rs adds no conflict: each merges with this change as it merges with #399's head. Of the open PRs that change docs/dynamodb-limits.md, #335 and #372 conflict in it with main as well, and this change adds no conflict there with any of them.

Rebase on main

Restacked on 31 October onto #399's head 1454cc9, which is rebased onto main at f49c5f8. The main PRs that changed files this change also changes are #511, #543 and #429 (see Merging). The four commits apply without conflicts, and none of this change's own lines changed (the range-diff above). The runs in the Tests section were made on 2026-10-26, before the rebase, with #399's head of that day (4f4fc21) as the base.

At 8549bc0: cargo fmt --all --check and cargo clippy --locked --workspace --all-targets -- -D warnings on 1.97.0 clean; cargo check --locked --workspace on 1.88.0 passes; cargo test --locked --lib passes for core (732), engine (192) and server (237). tests/test_document_path_length.py (53), tests/test_fgac_leading_keys.py (31) and #429's tests/test_gsi_multi_range_query.py (63, and one case skipped that runs only on a backend that refuses a condition on a later RANGE attribute) pass on a SQLite server and on a PostgreSQL server built from this head.

CI passed all 30 checks on 8549bc023.