[LeeroyHannigan]

Fixes #410.

Depends on #409 (fix/item-size-parity): this branch is rebased on it and reuses the PostgreSQL standalone UpdateItem index-key checks it adds. Merge #409 first, or merge this after rebasing once #409 lands. The diff against main shows both changes until then.

What was wrong

On the Cassandra backend, UpdateItem and the Put and Update members of TransactWriteItems did not check secondary-index key attributes on the item they were about to write. An UpdateExpression that set a GSI or LSI key to an empty string, an empty binary, or a value of another type was accepted with HTTP 200 and stored; later writes to that item failed inside the index row write with HTTP 500.

Measuring the fix against the service showed that SQLite, PostgreSQL and MongoDB, which did check the written item, applied the checks in a different order and with a different cross-member precedence from the service. The measured rules are now applied on every backend from shared code.

What the service does

Every rule was measured verbatim on live DynamoDB.

UpdateItem:

• A literal operand assigned to a secondary-index key (SET k = :v, ADD k :v, DELETE k :v, list_append of literals) is checked on the statement, ahead of the ConditionExpression and ahead of applying any action. Wording: Type mismatch for Index Key <attr> Expected: <T> Actual: <U> IndexName: <index>.
• A value computed from the existing item (an attribute reference, the fallback of if_not_exists when the attribute is absent) is checked after the condition passes and the statement is applied: The update expression attempted to update the secondary index key to unsupported type.
• A key the statement leaves empty is refused after the condition passes, with the update-expression wording.

TransactWriteItems:

• A wrong-typed index key is a positional ValidationError cancellation reason; an empty index key is a top-level ValidationException with no CancellationReasons. On a Put member both checks run ahead of the member's condition; on an Update member the literal check runs ahead of the condition, the computed-value and empty checks after it.
• Across members: a wrong-typed key on any member (table key or index key) cancels the transaction with the first such member's ValidationError in position and None everywhere else, whatever those members' own faults were. Otherwise an empty index key on any member is the top-level ValidationException, outranking failed conditions and unapplicable statements elsewhere.

Changes

• core: validate_index_key_literal_operands, validate_index_key_types_after_update, and on CancellationReason two internal reason constructors plus resolve_key_faults, which applies the cross-member precedence. The internal codes never reach a client.
• engine: UpdateItem runs the literal pass before dispatching to storage.
• storage-cassandra: post-apply checks on UpdateItem; compute_transact_update shared by the first PREPARE pass and the create-race retry; both checks ahead of the condition on a Put member; table-key failures tagged in all four arms; reasons resolved after rollback.
• storage-sqlite, storage-postgres, storage-mongodb: every member's key checks (table key, Put item index keys, Update literal operands) run in a pre-pass before any row is read or locked, so a request the precedence already decides never waits on a row another transaction holds (the contract twi_conflict.rs pins). The Update arms then run the computed-value check after apply; the per-op Validation variant that aborted on the first empty key is removed and reasons are resolved after every member has run. Standalone UpdateItem on all three reports a computed value with the service's wording.
• docs/differences-from-dynamodb.md: the rules and the known shared differences.

Tests

tests/test_index_key_validation_on_update.py: 64 dual-target cases covering each path, each fault, each index kind, the positional reason, the no-write guarantee, the ordering against a condition on Put and Update members, the cross-member precedence including table keys, if_not_exists, and the literal versus computed split. They pass against live DynamoDB and against servers built from this commit on Cassandra, SQLite, PostgreSQL and MongoDB, with no backend-specific skips. On main 26 of the first 31 fail on Cassandra. The core resolver has four unit tests.

Full pytest suite against servers built from this commit: SQLite 1,148 passed, PostgreSQL 1,131 passed, Cassandra 1,095 passed. Remaining failures in those runs were the import/export tests (which need the run-tests restart step CI arranges) and, on Cassandra, GSI-reading tests under the default propagation delay (#407); none touches this change. Workspace lib tests (1,232), cargo fmt, clippy on 1.97.0 with -D warnings, and the 1.88 MSRV build are clean.

Known shared differences, measured and left as they are

• An empty index key supplied through the legacy AttributeUpdates parameter is reported with the update-expression wording; the service uses the PutItem wording naming the index.
• A request whose own value exceeds 400 KB is refused for size by the service before any index-key check; ExtendDB reports the index-key fault first.
• A transacted Update whose Key has the wrong type answers the Type mismatch wording; the service says the key element does not match the schema.
• The service's position of the literal-empty check relative to the condition varied across tables when measured repeatedly (one table of five answered empty-first). The two tests pinning empty-after-condition follow the majority and can disagree with live DynamoDB on a table that lands the other way.

Two pre-existing Cassandra defects surfaced while measuring and are filed separately: #414 (a lost create race can leave an LSI row behind) and a Query with an empty-string key value returning 500 instead of the service's 400, which I will file next.

[LeeroyHannigan]

Rebased on main at abf8082, on top of the rebased #409 (827edb9); conflicts in crates/storage-postgres/src/data/transactions.rs, crates/storage-postgres/src/data/update_item.rs, crates/storage-sqlite/src/data/transactions.rs, crates/storage-sqlite/src/data/update_item.rs and docs/differences-from-dynamodb.md, resolved by keeping this branch's key-check pre-pass and post-apply wording with #401's index attribute definitions from the write's own catalog read.

On PostgreSQL and SQLite the Put arms call transact_op_key_checks, and transact_op_key_checks and the Update arm's post-apply check pass super::index::fresh_attr_defs where this branch passed the cached definitions. The PostgreSQL standalone UpdateItem check is #401's block, now calling validate_index_key_types_after_update. This branch's docs row goes after #401's two new rows in the Secondary Indexes table. devtools/run-tests no longer conflicts, since #409 now carries main's version.

#401's storage-level test update_item_rejects_a_wrong_typed_gsi_key calls the storage engine past the engine's statement pass, so it now expects "attempted to update the secondary index key to unsupported type". tests/test_index_key_validation_on_update.py (64) and tests/test_item_size_at_limit.py (58) pass on PostgreSQL.