[LeeroyHannigan]

Closes #435.

Summary

The service refuses a Query whose key condition values exceed the key size limits before it reads anything; ExtendDB ran the Query. This change adds the check with the service's sentences and ordering.

Measured on the service on 2026-10-23 (every row repeated, identical answers):

Shape	Service answer
HASH value of 2049 bytes (table, LSI, GSI, legacy KeyConditions)	One or more parameter values were invalid: Size of hashkey has exceeded the maximum size limit of2048 bytes (no space after of)
HASH value of 2048 bytes	accepted
Two HASH attributes, 1025 + 1024 bytes, or 2048 + 2048	One or more parameter values were invalid: Aggregated size of all hash keys has exceeded the size limit of 2048 bytes
Two HASH attributes, 1024 + 1024 bytes	accepted
Two HASH attributes, one value of 2049 bytes	the single hash sentence
RANGE value of 1025 bytes, any operator; or RANGE values adding up to 1025 (512 + 513, 600 + 1 + 600, 600 + BETWEEN with a 600-byte larger bound)	One or more parameter values were invalid: Aggregated size of all range keys has exceeded the size limit of 1024 bytes
RANGE total of exactly 1024 bytes; BETWEEN with two 600-byte bounds	accepted (BETWEEN contributes its larger bound)
Oversized HASH and RANGE in one request	the hash sentence (single or aggregated)
683 U+20AC characters (2049 bytes) in a HASH value; 342 (1026 bytes) in a RANGE value	refused by UTF-8 byte length; 682 plus xx and 341 plus x accepted
Undefined #name or :value in the key condition with an oversized value	the undefined-reference sentence first

Ordering, measured with a 2049-byte value: filter syntax, unused names and values, index name, ConsistentRead on a GSI, missing table, Limit, projection syntax and overlap, the Select conflicts and the filter operand type are reported before the size check; the ExclusiveStartKey checks after it.

Changes

• crates/core/src/validation/key_size.rs: the check, with the limits from the configuration and the sentences naming them. Unit tests in validation/key_size/tests.rs.
• handle_query calls it after the expression validations and before the start key checks.
• docs/dynamodb-limits.md: the partition key cell names the HASH sum.

Tests

• tests/python/test_query_key_size.py, test_query_key_size_values.py, test_query_key_size_order.py (shared fixtures in query_key_size_support.py): 64 rows, each asserting the exact sentence. 64 passed against the service.
• On ExtendDB alone (SQLite and PostgreSQL): 59 passed, 5 skipped. The five skipped rows use two or more RANGE clauses on one index, a shape the handler refuses earlier today as Query condition missed key schema element: h; the skip is a capability probe that lifts itself once the multi-attribute range change in fix(query): classify and order key conditions on a multi-attribute GSI the way the service does #429 merges. On a tree with fix(query): classify and order key conditions on a multi-attribute GSI the way the service does #429 merged all rows pass.
• Mutants against the wire files: character-count sizing, BETWEEN by one bound only, the HASH sum removed, the aggregated sentence checked before the single one, the check moved above the filter parse or below the start key check, each fails at least one row.
• git merge-tree against fix(query): classify and order key conditions on a multi-attribute GSI the way the service does #429 and against the Query accepts an ExclusiveStartKey from another partition and returns an empty page #440 and Query: a lone non-equality condition on the partition key gets the parser's message, not the service's #427 branches: clean.

Related

• The undefined-name row (pk = :v AND #n = :w, #n undefined) is unit level only: ExtendDB has no undefined-name refusal for a sort key clause today; fix(query): refuse a key condition with no HASH equality the way the service does #479 adds it, and with both merged the row matches the service.
• Cassandra, two things the new rows exposed, both reproduced on a cassandra:4.1 node:
  • The Cassandra backend wrapped a missing index name as Index nope not found inside IndexNotFound, so the Query sentence read The table does not have the specified index: Index nope not found on Cassandra only. Corrected to pass the bare name like the other backends (one line in storage-cassandra/src/data/index.rs).
  • The Cassandra backend cannot read a multi-RANGE index at all: every Query on such an index is refused by the node (Order by currently only supports the ordering of columns following their declared order in the PRIMARY KEY, because the data table's clustering key is sk_s, sk2_s, ..., base_pk and the Query emits ORDER BY sk_s, base_pk) and surfaces as InternalServerError, with or without a RANGE clause, for any value size. Not a one-line change (the single sort key model also drives the pagination restrictions and the start key read). The idx accept rows skip on that backend through the same capability probe, with the reason named; the defect will be filed on its own.

Pre-existing, measured, not changed here

• A BETWEEN whose lower bound is above the upper bound: the service refuses it (The BETWEEN condition was provided a range where the lower bound is greater than the upper bound), ExtendDB runs it.
• Two conditions on one key: KeyConditionExpressions must only contain one condition per key on the service, 200 here.
• A Number with 39 or more digits: Attempting to store more than 38 significant digits in a Number on the service, 200 here.
• A FilterExpression on a key attribute: Filter Expression can only contain non-primary key attributes: Primary key attribute: pk on the service, 200 here.

These will be filed as one issue together with the ones from #479.