[LeeroyHannigan]

Fixes #554. Fixes #555. Stacked on #548, which owns the UpdateTable sentences this changes.

CreateTable and an UpdateTable GSI Create now check AttributeDefinitions against each key schema with DynamoDB's rules and sentences, and refuse a name defined twice.

What the service answers

Measured on 2026-10-25 and on 2026-10-26 at 01:27, 01:29, 02:27 and 02:34 UTC in us-east-1, each request twice with the same answer. No request created or changed a table: every CreateTable named an existing table, and every UpdateTable carried a key with no definition or a duplicate the service refuses.

• A table billing fault (throughput given with PAY_PER_REQUEST, or missing with PROVISIONED) is reported before any definition fault.
• A name defined twice answers Attribute Name is duplicated: <name>, naming the first name whose second definition comes first ([b, a, b, a] names b). It comes before a missing key and applies to two definitions of one name with different types. The service checks it after the rule that one attribute cannot be both HASH and RANGE and after the length rule below, and before the other key schema checks.
• The table's key schema is checked first, then each LSI's, then each GSI's.
• A schema with more keys than there are definitions answers Invalid KeySchema: Some index key attribute have no definition. This is the rule behind fix(streams, update-table): CreationRequestDateTime; measured UpdateTable sentences and validation order #548's empty-member row and the "two or more missing keys" row of The Keys and AttributeDefinitions lists in the undefined-index-key sentence differ from the service #554: definitions [pk] for keys g, r answer it, while [pk, z] for the same keys answer the listing sentence below.
• Otherwise, a key with no definition answers One or more parameter values were invalid: Some index key attributes are not defined in AttributeDefinitions. Keys: [...], AttributeDefinitions: [...], with every key of that schema and every definition.
• On UpdateTable, a definition that redefines the table's own key with another type beside a valid Create is accepted, and the table keeps its type (UpdateTable accepts a redefined table key type and a duplicated AttributeDefinitions entry #555's first row).

The service orders the two lists in a way that is neither the request's nor alphabetical and does not depend on the attribute types: [pk, g] renders [pk, g], [g, pk] renders [g, pk], [pk, r] renders [r, pk], and keys hk, rk render [rk, hk]. ExtendDB lists keys in key schema order and definitions in request order.

What changed

• crates/core/src/validation/key_definitions.rs (new): validate_unique_attribute_definitions and validate_key_schema_defined, with unit tests.
• crates/core/src/validation/mod.rs: CreateTable calls them for the table, each LSI and each GSI in that order, in place of the loop that named the first missing key of all schemas together. The unused format_attr_defs goes. The table billing check now runs before the definition checks, so a billing fault is reported first as on the service; before this change a billing fault was reported after a missing key.
• crates/engine/src/update_table.rs: the GSI Create branch keeps fix(streams, update-table): CreationRequestDateTime; measured UpdateTable sentences and validation order #548's sentence for an absent member and calls the two checks for the rest.
• crates/engine/src/update_table_tests.rs: fix(streams, update-table): CreationRequestDateTime; measured UpdateTable sentences and validation order #548's row for one definition and two keys expected the listing sentence; it now expects the key schema sentence, as measured. fix(streams, update-table): CreationRequestDateTime; measured UpdateTable sentences and validation order #548's row for one undefined name and two keys is removed, since it is the same case, and two rows are added (a listing with every key, a duplicate).
• docs/differences-from-dynamodb.md: a row for the order of the two lists.

The redefinition row needed no code change: the backends already keep the stored definition of a name the table has.

Related behaviour

Measured differences that exist on #548's head and on main as well:

• CreateTable checks the key schema shape (first element not HASH, second not RANGE, one name as HASH and RANGE) and the vector index attribute rules before the table billing, the duplicate and the key definition checks; the service checks the billing, the duplicate and the definitions first. UpdateTable checks vector index faults before the duplicate and the GSI listing.
• The texts for a first element that is not HASH, a second that is not RANGE, PROVISIONED without throughput, and one name as table HASH and RANGE given as many definitions as keys differ from the service's.

Tests

tests/test_key_schema_definitions.py: 31 dual-target wire tests from the measurements. The lists in the listing sentence are compared as sets. The redefinition test waits for its index to be active before the table is deleted.

Run locally at the head 2bb47d61b, on a SQLite server and a PostgreSQL server built from it:

• the new file: 31 passed on each. On a SQLite build of fix(streams, update-table): CreationRequestDateTime; measured UpdateTable sentences and validation order #548's head 6eff5029f: 27 failed, 4 passed. The 4 that pass there are the one-key UpdateTable listing ([g] against [pk]), the one-key CreateTable listing ([pk] against [x]), the billing fault beside a duplicate (fix(streams, update-table): CreationRequestDateTime; measured UpdateTable sentences and validation order #548 has no duplicate check) and the redefinition row.
• every file under tests/ matching update_table, create_table, table_operations, gsi, lsi, throughput or billing, with the new file, and the six tests/python files matching table, gsi, lsi, index or stream: 163 passed on each backend. The 5 tests of tests/test_gsi_async_queue.py need a PostgreSQL connection string and stop at setup on SQLite; the 5 of tests/test_gsi_async_queue_sqlite.py skip on PostgreSQL. tests/test_gsi_async.py calls the settings CLI at ./target/release/extenddb, which these runs provided.
• cargo +1.97.0 fmt --all --check, cargo +1.97.0 clippy --locked --workspace --all-targets -- -D warnings, cargo +1.97.0 check --locked --workspace --all-targets, cargo +1.88.0 check --locked --workspace, and the extenddb-core and extenddb-engine unit tests (698 and 185 passed).

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

Files

crates/core/src/validation/mod.rs goes from 3,803 to 3,802 lines and crates/engine/src/update_table.rs from 384 to 355. The new checks are in the 169-line key_definitions.rs.

Rebase on #548's head

Rebased onto #548's head 6eff5029f, which now sits on main 817b2405d. The two copies of #548's commits this branch carried are dropped; they differ from #548's own commits only by the author address and by context lines main changed. The four commits of this branch apply without conflicts and their patches are unchanged.

Between the two bases, main changed one code file this branch touches. #401 replaced the online index limit sentence in validate_vector_index_updates with the ONLINE_INDEX_LIMIT constant, in crates/core/src/validation/mod.rs, about 360 lines above the hunk this branch changes there. That function runs on UpdateTable's vector index path, before the GSI checks, as "Related behaviour" says, and it adds no check to CreateTable. #522 added two rows to the tag operations table of docs/differences-from-dynamodb.md; this branch's row is in the Control Plane table above it. The order of the checks described above holds on CreateTable and on the UpdateTable GSI Create branch after the rebase.

CI passed all 29 checks on 2bb47d61b.

Merging

This is based on #548's branch. After #548 merges, retarget it to main.

git merge-tree --write-tree of the head against the 33 open PRs that change validation/mod.rs, update_table.rs, update_table_tests.rs or docs/differences-from-dynamodb.md, compared with the same merge of #548's head, adds conflicts with eight. #481, #485 and #700 each add a pub use on the line this adds at the top of validation/mod.rs; keep both lines. #399, #507, #515, #531 and #550 each add a row to the Control Plane table of docs/differences-from-dynamodb.md after the same line as this change's row; keep both rows. The other conflicts are the same with or without this change; #474 moves validate_gsi_updates out of update_table.rs, so it carries the new GSI Create branch to its new place.