Repository navigation
CreateTable reports a global secondary index name outside the pattern at 'indexName', where DynamoDB names the member #904
Description
What ExtendDB does
validate_index_name in crates/core/src/validation/mod.rs writes the location as indexName for every index name it refuses. For a global secondary index of CreateTable the location DynamoDB gives is the member path.
Measured on 2026-11-06 at the head of #830 (ccdae81), SQLite and PostgreSQL:
| Request | ExtendDB |
|---|---|
CreateTable with one GSI named g i |
1 validation error detected: Value 'g i' at 'indexName' failed to satisfy constraint: Member must satisfy regular expression pattern: [a-zA-Z0-9_.-]+ |
CreateTable with GSIs gok and g<U+0000>i |
the same sentence with Value 'g<U+0000>i' at 'indexName' |
What DynamoDB does
Measured in us-east-1 on 2026-11-06, with SDK parameter validation off. The index position is 1-based:
| Request | DynamoDB |
|---|---|
one GSI named g i |
1 validation error detected: Value 'g i' at 'globalSecondaryIndexes.1.member.indexName' failed to satisfy constraint: Member must satisfy regular expression pattern: [a-zA-Z0-9_.-]+ |
GSIs gok and g<U+0000>i |
... Value 'g<U+0000>i' at 'globalSecondaryIndexes.2.member.indexName' ... |
Suggested fix
Report a CreateTable GSI name fault at globalSecondaryIndexes.<n>.member.indexName. #830 does the same for UpdateTable (validate_update_index_name in crates/engine/src/update_table.rs, globalSecondaryIndexUpdates.<n>.member.create.indexName). The location for a local secondary index name and for the length clause is unmeasured. Measure it before changing it.
Activity