[LeeroyHannigan]

What

Issue #108 lists 106 requests whose response differs from Amazon DynamoDB. This change makes ExtendDB validate expressions and transactions in the service's order and return the service's messages for the groups below. Every expectation was measured against the service (us-east-1, 2026-10-14), and every new test file was run against the service before it was run against ExtendDB.

Semantic validation of expressions. After the grammar pass, the service walks the parsed expression once, in expression order, checking each node after its operands, then checks overlapping paths, then unused names and values. New validate_update_semantics and validate_condition_semantics in crates/core/src/expression/semantics/ (one file per rule family) follow that walk. The parsers now do grammar only, keep function names as written, and record section order for the walk.

• UpdateExpression: + and - take numbers, list_append takes lists, ADD takes a number or a set, DELETE takes a set. A placeholder of the wrong type is refused with the service's type vocabulary (S, N, L for operators and functions; STRING, NUMBER, Binary, BOOL, NULL, LIST, MAP for ADD and DELETE). Function names are case-sensitive: IF_NOT_EXISTS(x, :v) and foo(x) are Invalid function name, a condition function is not allowed in an update expression, list_append is refused as an operand of a function or of +, both functions take two operands, and the first operand of if_not_exists is a document path. A repeated section is reported after that section's own actions, so SET a = :v SET b = :q reports :q. Before this change IF_NOT_EXISTS(x, :v) was accepted and written, and DELETE s :string was accepted when s did not exist. SET a = :string + :n was already refused when it was evaluated (An operand in the update expression has an incorrect data type); it is now refused before the table is read, with the service's text.
• ConditionExpression and FilterExpression: the six condition functions are matched as written (ATTRIBUTE_EXISTS(pk) was accepted and evaluated); if_not_exists and list_append are not allowed in a condition expression; a boolean function in operand position and size in condition position are not allowed to be used this way; operand counts are fixed per function; attribute_exists and attribute_not_exists take a document path; begins_with takes a string or binary and attribute_type a string naming a type, both checked at request time with the operation's prefix.
• Every unused name or value is listed in one set, sorted, so the message is the same on every backend. It named one key chosen by hash order, which differed between backends and processes.

Legacy conditions. ScanFilter, QueryFilter and KeyConditions bypass the expression parser, so they get their own request-time check, ahead of the desugaring and the table lookup, with the rules measured against the service on 2026-10-23 for every ComparisonOperator and AttributeValue type: the operator name (Invalid comparison operator), the value count (Invalid number of argument(s) for the <op> ComparisonOperator), the first value's type (ComparisonOperator <op> is not valid for <type> AttributeValue type), that every value has the first value's type, and that a BETWEEN lower bound is not above its upper bound, each with the One or more parameter values were invalid: prefix. A range key operator the service does not index (NE, NULL, NOT_NULL, CONTAINS, NOT_CONTAINS, IN) in KeyConditions is refused with Attempted conditional constraint is not an indexable operation. Before this change a ScanFilter with BEGINS_WITH and a number returned 200 on an empty table.

Request stage on the read APIs. Query and Scan check the FilterExpression, then the KeyConditionExpression (with its Invalid KeyConditionExpression: prefix and ahead of the key schema match, so an undefined #n is reported as such), then the ProjectionExpression, then unused names and values, all before the table is looked up. An undefined :q in a filter returned 200 on an empty table. Limit and Segment checks precede the expressions on Scan. A KeyConditionExpression function name is answered by name: contains, attribute_exists, attribute_not_exists and attribute_type give Invalid operator used in KeyConditionExpression with no function name, size gives KeyConditionExpressions cannot contain nested operations, and any other name, Begins_With included, gives Invalid function name; function: <name>. The first undefined #name or :value in the text is the one named, names and values alike. A Limit under 1 on Query and Scan gives 1 validation error detected: Value at 'Limit' failed to satisfy constraint: Member must have value greater than or equal to 1, ahead of the table lookup and every expression. On Scan, the range checks on Segment and TotalSegments come first, and the checks that the two go together and that Segment is below TotalSegments come after the expressions and the unused names and values and before the table lookup.

Single-item order. UpdateItem checks the whole ConditionExpression before the UpdateExpression. PutItem, UpdateItem, and DeleteItem wrap every expression-stage error in 1 validation error detected: and omit the : ConditionExpression is null suffix; the read, batch, and transaction APIs return the messages bare. The expression size: N suffix follows the operation (present on a Scan FilterExpression and a transaction ConditionExpression, absent on a Query FilterExpression and the single-item ConditionExpression). Eleven assertions in three existing dual-target test files asserted the unprefixed text and fail against the service (test_expression_error_prefix.py 3, test_expression_param_usage.py 6, test_expression_size_limit.py 2); they are corrected, and one assertion is added to the third file. Legacy AttributeUpdates with an ADD of a value that is not a number or a set, or a DELETE with a value that is not a set, are refused with 1 validation error detected: One or more parameter values were invalid: ADD action is not supported for the type S (and DELETE action with value is not supported for the type N), ahead of the table lookup and key validation. A ConditionCheck with an empty ConditionExpression gives Invalid ConditionExpression: The expression can not be empty;.

Transactions. TransactGetItems and TransactWriteItems validate in phases, each over every item before the next. TransactWriteItems checks, one item after another and before any table is looked up, the nesting of the item's ExpressionAttributeValues (32 wrappers pass, 33 do not), its expressions (UpdateExpression before ConditionExpression), the unused names and values, and for a Put the attribute name size, the 400 KB item size and the item nesting. Then it looks the tables up, checks the 4 MB total, and makes one pass over the items in order that stops at the first failing item: a key that does not fit the schema, then a key attribute named in an Update (both a cancellation with ValidationError on that item and None on every other item), then an empty key value (a top-level ValidationException). Duplicate targets come next, and last an Update that stores a value nested as deep as an item may not hold, which is a ValidationError reason on every such item. TransactGetItems checks the projections, looks the tables up, checks the key schema (first offending item only) and then duplicate keys. An undefined reference is the request error the service returns rather than a per-item cancellation reason, and a key schema mismatch leaves the other items' conditions unevaluated. TransactWriteItems returns "ItemCollectionMetrics": {} when SIZE is requested and no table has a local secondary index, and the ConsumedCapacity entries of both transaction APIs are ordered by table creation time, oldest first, as measured on the service (section below).

Key-shaped messages. GetItem, DeleteItem, UpdateItem, BatchGetItem, and BatchWriteItem (Put and Delete) refuse a key with a missing, mistyped, or extra attribute with The provided key element does not match the schema. PutItem keeps Missing the key pk in the item and Type mismatch for key. BatchWriteItem returns "ItemCollectionMetrics": {} under SIZE with no LSI.

Table ARNs in TableName (eight #108 rows) stay unsupported by decision: an ExtendDB table ARN names ExtendDB's account and region, so a table that streams or replicates to Amazon DynamoDB would answer to two ARNs. docs/differences-from-dynamodb.md records this. Open PR #200 takes the opposite position and needs reconciling before either merges.

This is one PR with three pieces that can be read on their own. The legacy condition validator (legacy_filter.rs, legacy_filter_tests.rs, and the 79 wire cases in tests/test_expr_operand_type_and_size.py) is in aef6e1b, 475465a and 90fdc32. The ConsumedCapacity order is in 68dcd0a, 217b5f9 and b7ba331: the creation_date_time field on TableKeyInfo, the column read in the SQLite, PostgreSQL and Cassandra storage crates, the MongoDB catalog write that keeps milliseconds, and tests/test_transact_capacity_order.py. The decision to keep table ARNs in TableName unsupported is one row in docs/differences-from-dynamodb.md, added in 29229c2 with the semantic pass. Commits ac76c66 and 964f3c3 only move code: the semantic pass split by rule family, and the update parser tests into their own file. The six commits from af5f681 to cbb04f0 change the transaction phases, the Query key condition checks, four request stage texts, the Scan parameter order, and add tests for each.

Why

Closes part of #108. A client that maps on the service's error codes and messages, or that reads CancellationReasons, ItemCollectionMetrics, or ConsumedCapacity, saw different responses from ExtendDB on these requests, and request shapes the service refuses were accepted: a function name in the wrong case, a DELETE of a string on an absent attribute, a repeated update section, overlapping update paths, a nested list_append, and an if_not_exists whose first operand is not a path.

Of the 106 rows in #108, 83 returned the service's status, error type, and message (30 on main) when measured on this branch on 2026-10-14, before the legacy condition work above. The 24 that remained are in these groups:

• the parser's syntax wording (Syntax error; token: X, near: Y; 14 rows);
• the ResourceNotFound message text (3 rows);
• the table ARN rows (5), unsupported by decision;
• the service's rendering of an over-limit list value in the 1 validation error detected message (2 rows: 101 transaction items, 26 batch writes).

The 4 MB transaction message also remains: the service's text carries its own serialized payload size.

Testing done

• tests/test_expression_semantics.py (new, 159 cases): operand types, function names, the walk order, the unused set, condition function rules, Query and Scan request-stage checks, key-shaped messages, BatchWriteItem ItemCollectionMetrics. tests/test_transact_validation_order.py (new, 31 cases): the transaction phases, first-offender cancellation, item size and 4 MB positions. tests/test_update_expression_rules.py (new, 37 cases): repeated sections, operands, overlap, the single-item prefix. Every expected response was captured from the service; all three files pass against the service and on SQLite, PostgreSQL, and MongoDB. 164 of the 186 cases in the first two fail on main.
• The expression, validation, transaction, batch, query, and scan suites pass on all three backends (767 on SQLite and PostgreSQL, 751 on MongoDB with the four test_transact_absent_item_isolation cases of fix(postgres): lock missing items that TransactWriteItems checks or deletes #387 unchanged). The remaining full-suite failures on a dev-mode SQLite server (metrics, import and export, gsi async, misc operations) are identical on main and need infrastructure the dev server lacks.
• Unit tests for the semantic pass in semantics/tests.rs (10) pin the walk order and the per-node rules inside one expression. The orders between expressions and stages (condition before update, the Query stages, the transaction phases) are pinned by the wire tests. At 4f4fc21: cargo test --workspace 2,021 passed on stable; on 1.88.0, 1,784 passed with the Cassandra crate excluded, because the local Cassandra node was held by another workload (that crate passed on stable in the same run); cargo fmt --check and cargo clippy --all-targets -- -D warnings on 1.97.0 clean.
• tests/test_transact_capacity_order.py (new, 6 cases) and the legacy condition cases in tests/test_expr_operand_type_and_size.py and tests/test_expression_param_usage.py: measured on the service on 2026-10-23. The eight test files this PR adds or changes pass on MongoDB at 4f4fc21 (391 passed), including the ordering test with tables created within one second of each other.
• Latency of the changed paths on the dev-mode SQLite server, this branch against main, one client, two runs (p50): TransactWriteItems with 100 Puts 23.8 to 23.9 ms against 24.0 to 24.1; UpdateItem with 50 SET actions 1.48 to 1.50 ms against 1.47; PutItem with a 20-clause condition 1.17 to 1.19 ms against 1.18; an UpdateItem with an invalid expression 0.88 ms against 0.88 to 0.89.
• tests/test_transact_write_phase_order.py (new, 16 cases), tests/test_request_stage_checks.py (new, 30 cases) and tests/test_transact_value_nesting.py (new, 6 cases) pin the transaction check order, the key condition, Limit, Segment, legacy AttributeUpdates and empty expression texts, and the value nesting thresholds. Every expectation was measured on the service on 2026-10-27, two samples each, and all 52 cases pass against the service and against a SQLite dev-mode server. 861 tests pass on the dev-mode server across the transaction, expression, query, scan, item, batch and update files. At 95e90f8, cargo test -p extenddb-core -p extenddb-engine passes (530 and 187), cargo fmt --check and cargo clippy --all-targets -- -D warnings on 1.97.0 are clean for core, engine and storage-sqlite, and cargo check on 1.88.0 passes for core and engine. The workspace totals quoted in the next bullet were not re-run.

ConsumedCapacity order per backend

TransactGetItems and TransactWriteItems return one ConsumedCapacity entry per table, ordered by the table's creation time, oldest first. Two tables with the same stored creation time are listed in name order.

The precision of the stored creation time differs per backend, so the point at which two creates tie differs with it:

• SQLite: about 0.24 microseconds. The catalog text carries nanosecond digits, and the value the order uses is an f64 of epoch seconds.
• PostgreSQL: microseconds, from a TIMESTAMPTZ column.
• MongoDB: milliseconds. The catalog write used to drop the sub-second part, so two tables created inside one second tied and the array came back in name order. A catalog row written before that fix keeps whole seconds and still ties.
• Cassandra: milliseconds, from a CQL timestamp column.

Measured on SQLite, PostgreSQL and MongoDB. Cassandra reads the same catalog column, and the six cases of tests/test_transact_capacity_order.py pass on it in the Cassandra integration job at 4f4fc21.

Known differences

These are differences from the service on the legacy condition paths that this PR does not change, measured against the live service on 2026-10-23 and filed as #477. Since #429, main answers items 5 and 7 with the service's message for a table's own key attributes; the other six are present on main.

1. Two legacy condition entries that are both invalid: the service names the second entry in map order, ExtendDB names the first.
2. Query with a QueryFilter on a primary key attribute: the service refuses it, ExtendDB returns 200.
3. ScanFilter EQ with an N AttributeValue whose value is not a number: the service reports the numeric conversion, ExtendDB returns 200.
4. ScanFilter BEGINS_WITH with an N AttributeValue whose value is not a number: the service reports the numeric conversion first, ExtendDB reports the operator against type message.
5. KeyConditions on the sort key with a value whose type is valid but is not the schema type: the service refuses it with the schema type message, ExtendDB answered HTTP 500 before fix(query): classify and order key conditions on a multi-attribute GSI the way the service does #429.
6. KeyConditions EQ or BEGINS_WITH with an empty string: the service refuses it, ExtendDB returns 200.
7. KeyConditions EQ on an S partition key with an N value: the service refuses it with the schema type message, ExtendDB returned 200 before fix(query): classify and order key conditions on a multi-attribute GSI the way the service does #429.
8. BatchGetItem with ReturnConsumedCapacity TOTAL where every key is absent: the service returns one entry per table, ExtendDB returns an empty list.

Measured against the live service on 2026-10-27 and present on main:

9. An empty ConditionExpression on a transaction Put, Delete or Update, and on PutItem, UpdateItem or DeleteItem: the service answers Invalid ConditionExpression: The expression can not be empty;, ExtendDB treats it as no condition.
10. An attribute name over the limit: the service answers Attribute name is too large, must be less than 65536 bytes, ExtendDB words it differently. The boundary agrees.
11. A legacy ADD of an empty list: the service accepts it, ExtendDB refuses it.
12. Scan Segment and TotalSegments range checks: the service answers Value at 'TotalSegments' failed to satisfy constraint: ... and Value at 'Segment' ..., ExtendDB uses another wording, and its text for a Segment at or above TotalSegments ends with the two values.
13. A Scan with ExpressionAttributeValues and no expression that uses them: the service answers ExpressionAttributeValues can only be specified when using expressions, ExtendDB adds : FilterExpression is null.
14. An Update that stores a value nested as deep as an item may not hold is reported with the other items' condition results on the service (ValidationError next to ConditionalCheckFailed), and with None for them on ExtendDB.

Rebase on main

Rebased onto main at f49c5f8 on 31 October. The branch keeps its 17 commits in the same order; the merge commit f9355f5 is gone, and the first commit carries what that merge had resolved (table_key_info_uncached in transact_get_items.rs, the imports in transact_write_items.rs, and the table ARN row of the differences document). The commit ids in the What section are the ones on this head. The ids in Testing done and in the ConsumedCapacity section (4f4fc21, 95e90f8) name the heads those runs were made at, before the rebase.

The main PRs this branch was resolved against, and what changed in its code because of them:

• fix(auth): bind LeadingKeys for a refused Query's partition operand #511, crates/core/src/expression/mod.rs: fix(auth): bind LeadingKeys for a refused Query's partition operand #511 widened the key_condition re-export to KeyClauseOperand, KeyCondition, SortKeyCondition, key_condition_clause_operands and parse_key_condition, and this branch adds compare_orderable to the evaluator re-export. The file keeps both lines. fix(auth): bind LeadingKeys for a refused Query's partition operand #511's rule is unchanged for every key condition that parses. begins_with written in another case no longer parses, so it binds no LeadingKeys, as for any condition that does not parse.
• fix(streams): resolve the shard against its stream inside the GetRecords read #543, crates/storage-cassandra/tests/direct/stream_ownership.rs: fix(streams): resolve the shard against its stream inside the GetRecords read #543 added this test after this branch gave TableKeyInfo its creation_date_time field, so its one TableKeyInfo literal did not build. The commit that adds the field (68dcd0a) sets creation_date_time: 0.0 there, as it does in streams.rs.
• fix(query): classify and order key conditions on a multi-attribute GSI the way the service does #429, crates/engine/src/query.rs: fix(query): classify and order key conditions on a multi-attribute GSI the way the service does #429 added check_key_value_type and refuse_begins_with_on_number above validate_name_refs_in_expr. This branch removes validate_name_refs_in_expr, because its one call, the FilterExpression name check, is replaced by the semantic pass that parse_condition_checked runs on the filter. The file keeps fix(query): classify and order key conditions on a multi-attribute GSI the way the service does #429's two functions. fix(query): classify and order key conditions on a multi-attribute GSI the way the service does #429's key condition classification in handle_query sits where this branch moved the key condition handling, after the table and index lookup and before the Select checks.
• fix(mongodb): store the key when UpdateItem creates an item #473 changes no file this branch changes.

git range-diff 9d132022..17b805da f49c5f82..1454cc93: the first commit differs by the former merge's resolutions and by #429's lines in the handle_query code it moves and above the function it removes, and the fifth by the stream_ownership.rs line above. The other fifteen carry the same diff.

At 1454cc9: 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 (726), engine (192) and server (237), #429's 20 unit tests in key_condition.rs and leading_keys among them. The eleven test files this PR adds or changes, plus tests/test_fgac_leading_keys.py and #429's tests/test_gsi_multi_range_query.py, pass on a SQLite server and on a PostgreSQL server built from this head: 537 cases passed on each, and one case of tests/test_gsi_multi_range_query.py skipped, the one that runs only on a backend that refuses a condition on a later RANGE attribute. Against Cassandra 4.1 with password authentication, as the Cassandra integration job runs them, extenddb-storage-cassandra's unit tests (75) and direct storage tests (181) pass.

CI passed all 35 checks on 1454cc932.

Checklist

• I have read CONTRIBUTING.md
• All tests pass (cargo test --workspace)
• Code is formatted (cargo fmt --check)
• Clippy is clean (cargo clippy -- -W clippy::pedantic)
• I have added or updated tests for new functionality
• I have updated documentation if behavior changed
• Breaking changes are noted below (if any)
• If this changes the wire protocol, Storage trait, auth model, on-disk format, or public CLI surface, an RFC has been accepted or is linked below. Otherwise, an ADR captures the decision (link below).

ADR / RFC: n/a. The change alters wire-visible error text and response members toward the live service, which CONTRIBUTING lists under the RFC trigger; it is a parity fix measured against the service rather than a protocol proposal. A maintainer's call on whether an ADR is wanted.

Breaking changes

Requests the service refuses and ExtendDB accepted are now refused: function names in the wrong case in an UpdateExpression or a condition, a DELETE of a non-set value on an absent attribute, a repeated update section, overlapping update paths, a nested list_append, an if_not_exists whose first operand is not a path, and an undefined :value or #name in a Query or Scan filter (previously a 200 when no row was evaluated). Requests that evaluation already refused are now refused before the table is read, with the service's text: + or - on a non-numeric placeholder, ADD of a wrong type, and list_append of a non-list. A Scan with Segment and no TotalSegments now reports an expression error ahead of the missing parameter, as the service does. Error messages for these groups change to the service's text. Key mismatch messages on the key-shaped APIs change to The provided key element does not match the schema. ItemCollectionMetrics is present as {} on TransactWriteItems and BatchWriteItem under SIZE with no LSI. The ConsumedCapacity array of both transaction APIs is ordered by table creation time. ScanFilter, QueryFilter and KeyConditions conditions the service refuses are refused at request time with the service's messages.

---

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache License 2.0 and I agree to the Developer Certificate of
Origin (DCO). See CONTRIBUTING.md for details.

[jcshepherd]

What does "wins" mean in this context?

[LeeroyHannigan]

"Wins" meant precedence between two errors in one expression, and the comment did not say so. The grammar pass in parser.rs reports every syntax error first; the semantic checks (function name, whether a function may stand alone, operand count) run afterwards in validate_condition_semantics (crates/core/src/expression/semantics/condition_rules.rs:31), over the whole parsed tree. So for foo(pk) AND the response is the syntax error at the end of the text, not the unknown function name that appears first.

The service has the same precedence. Measured 2026-10-23 on PutItem: foo(pk) AND, ATTRIBUTE_EXISTS(pk) AND, begins_with(pk, :n) AND (with :n a number) and attribute_exists(#x) AND (with #x undefined) each answer Invalid ConditionExpression: Syntax error; token: "<EOF>", near: "AND"; foo(pk) alone answers Invalid function name; function: foo. The four cases are pinned in TestConditionFunctions.test_a_syntax_error_beats_the_semantic_errors in tests/test_expression_semantics.py (343c2fb).

I rewrote the comment to say this without the word (crates/core/src/expression/parser.rs:136-144, and the same wording in update_parser/mod.rs:279-286), in a8d83c6.

[jcshepherd]

A syntax error because there are no arguments? Please clarify.

[LeeroyHannigan]

Yes. The service's grammar needs at least one operand between the parentheses, so attribute_exists() and foo() are refused at the ) as a syntax error, Syntax error; token: ")", near: "()", before the function name or the operand count is looked at. Measured 2026-10-23 for both spellings on PutItem (ConditionExpression); the UpdateItem case SET x = foo() was measured 2026-10-14. One operand too few is a different error: begins_with(pk) parses and the semantic pass reports Incorrect number of operands for operator or function; operator or function: begins_with, number of operands: 1 (also measured 2026-10-23).

The check is at crates/core/src/expression/parser.rs:241-251 (and update_parser/mod.rs for SET operands); the wire cases are foo(), attribute_exists() and begins_with(pk) in TestConditionFunctions in tests/test_expression_semantics.py. I rewrote the comment to say this in a8d83c6.

[jcshepherd]

I can't tell if this is saying ExtendDB's behavior (in terms of sorting) is now equivalent to DynamoDB's, or if ExtendDB is providing firmer ordering guarantees than DynamoDB (and why).

[LeeroyHannigan]

It is now the service's order. DynamoDB documents no order for the ConsumedCapacity entries of a transaction, so I measured it on 2026-10-23 with three tables created on 2026-10-22, 2026-10-23 11:01 and 2026-10-23 14:45 UTC, with names that sort opposite to the creation order. For the request orders [newest, middle, oldest], [middle, newest, oldest] and [oldest, newest, middle], TransactGetItems and TransactWriteItems both returned the tables oldest first. The order follows neither the request nor the names, it follows the tables' creation time.

PerTableCapacity (now crates/engine/src/per_table_capacity.rs) orders the entries by creation time, oldest first, with name order breaking a tie. TableKeyInfo carries the creation time from the catalog row the handlers already read for the key schema, so there is no extra catalog read. Before this PR the handlers aggregated into a HashMap and the order changed between processes and backends.

Two tables tie when their stored creation times are equal, and the precision of that value differs per backend: nanoseconds on SQLite, microseconds on PostgreSQL, milliseconds on MongoDB and Cassandra. MongoDB was writing whole seconds, so three tables created inside one second got the same value and came back in name order; that write now keeps the millisecond part. A catalog row written by an earlier build still holds whole seconds. tests/test_transact_capacity_order.py creates three tables whose names sort opposite to their creation order and asserts the order on both operations; it runs against the service and against ExtendDB, and it passes on SQLite, PostgreSQL and MongoDB. docs/differences-from-dynamodb.md has the row under Capacity and Throttling, with the precision per backend.

[jcshepherd]

Where are these checks happening now?

[LeeroyHannigan]

The expression form moved them into the semantic pass. The legacy QueryFilter path lost them, which was a regression in this PR; it is fixed in 343c2fb and 4132394.

FilterExpression: the begins_with and ordering operand checks run inside the semantic pass, at request time, before the table lookup. The call is parse_condition_checked at crates/engine/src/query.rs:170, which runs validate_condition_semantics (crates/core/src/expression/semantics/condition_rules.rs:31); the begins_with operand type is at condition_rules.rs:131 and the ordering operand types at condition_rules.rs:54 and 60. The checks are in the walk because the service reports them in expression order with the other semantic errors (#x = :v AND begins_with(pk, :n) with an undefined #x reports the name, begins_with(pk, :n) AND #x = :v reports the operand type; both in TestConditionFunctions). Covered by tests/test_expr_operand_type_and_size.py and tests/python/test_begins_with_type_check.py.

QueryFilter (legacy): desugar_filter bypasses the parser, so the removal left that path with no request-time check; an empty table returned 200 and a non-empty one failed on the first row evaluated. The service checks each legacy condition at request time, before the table lookup, with its own messages. I measured the full operator by type grid on 2026-10-23: One or more parameter values were invalid: ComparisonOperator BEGINS_WITH is not valid for N AttributeValue type and the same text for every other refused pair (EQ and NE take every type; BEGINS_WITH takes S and B; CONTAINS and NOT_CONTAINS take S, N, B, BOOL and NULL; the ordering operators, BETWEEN and IN take S, N and B), plus the value count (Invalid number of argument(s) for the <op> ComparisonOperator), mixed types (AttributeValues inside AttributeValueList must be of same type), an inverted BETWEEN range and an unknown operator name. validate_legacy_condition in crates/engine/src/legacy_filter.rs now runs those checks on each QueryFilter, ScanFilter and KeyConditions entry before it is desugared, with the service's text; the Invalid FilterExpression: wording is gone. The grid is pinned in the engine's unit tests (legacy_filter_tests.rs) and one row per message on the wire in TestLegacyFilterOperandType in tests/test_expr_operand_type_and_size.py.

[jcshepherd]

Similar question to query.rs: where are these checks happening now?

[LeeroyHannigan]

The answer is the same as for Query. FilterExpression: inside the semantic pass through parse_condition_checked at crates/engine/src/scan.rs:197, before the projection, the unused check and the table lookup (scan.rs:300); the begins_with and ordering operand checks are at crates/core/src/expression/semantics/condition_rules.rs:131, 54 and 60.

ScanFilter (legacy): the check had been dropped. 343c2fb and 4132394 restore it in desugar_filter (validate_legacy_condition in crates/engine/src/legacy_filter.rs) with the service's messages, measured 2026-10-23 on an empty table for every operator and type: BEGINS_WITH with a number answers One or more parameter values were invalid: ComparisonOperator BEGINS_WITH is not valid for N AttributeValue type, LT with a boolean names BOOL, BETWEEN with a list then a number names L, and the value count, mixed types, inverted BETWEEN range and unknown operator get their own texts. The ScanFilter rows are in TestLegacyFilterOperandType in tests/test_expr_operand_type_and_size.py.

[jcshepherd]

Some of the agent-generated comments are read pleasantly but actually are ambiguous which makes it hard to determine whether the code is even solving a real problem. I flagged a couple. Also some operand validation code in query.rs and scan.rs was deleted and it's not obvious that it is still being done somewhere (assuming it was needed).

[jcshepherd]

Unused.

[jcshepherd]

Dead code in resolver.rs: otherwise okay.