Repository navigation
[Bug] List of wrong error types, wrong error messages, and missing validations #108
Description
Describe the bug
There are about 100 validation differences I found between DynamoDB and ExtendDB for validations and error messages and codes.
I had an LLM pull my DynamoDB parity tests out of u19r/aux-storage, mainly https://github.com/u19r/aux-storage/tree/main/crates/storage-api/src/routes and adjacent _test files and run them against ExtendDB and write up all conditions and failure in a markdown document.
Most of the issues are slight mis-wording, extra information, missing information. There are a class of errors that appear to be due to the order in which validations are run, and there are a set of missing validations where ExtendDB fails to return a 400 error.
To Reproduce
Table rows include the operation to run, the payload, the expected output payload, the ExtendDB payload, and an LLM generated note.
Expected behavior
ExtendDB replicates DynamoDB behaviour
Actual behavior
There remain inconsistencies in the 400 errors and some validations remain uncaught.
Environment
- ExtendDB version: 0.1.0
- Operating system: macOS 26
- Rust version (if building from source): 1.94
- Client SDK/driver and version: CLI
- Deployment method (binary, container, source): source
Additional context
If a standalone test suite crate would be helpful to you I can refactor my tests to pull together all dynamodb conformance tests in a new crate.
Checklist
- I have searched existing issues for duplicates
- I have included the ExtendDB version and environment details
- I can reproduce this with the latest release
Activity
LeeroyHannigan commentedon Oct 25, 2026
Status of the attachment's rows against
main(744ea29) and the open PRs, from reading the code:Fixed on
main:COUNTas a bare reserved word in aKeyConditionExpression, a reserved word in a TransactGetItemsProjectionExpression, and an unusedExpressionAttributeNamesentry in BatchGetItem (fix: validate expression attributes and label parse errors per parameter #162, fix: validate expression attribute entries and enforce expression size limits #181).Invalid expression:label on reserved words in GetItem, BatchGetItem, Scan and TransactWriteItems expressions (fix: validate expression attributes and label parse errors per parameter #162, fix: validate transaction expression attributes and label parse errors per parameter #169).ExclusiveStartKeywithout the base keys, and a baseExclusiveStartKeywithout the sort key (fix: match real DynamoDB on Scan and Query ExclusiveStartKey malformations #86).Tracked in other issues:
Syntax error; token: ..., near: ...rows are the family Condition expressions: three shapes the service refuses or words differently (measured 2026-10-24) #501 covers; fix(expression): operator cap, syntax error wording, PutItem map keys #558 changes that wording for repeated and misplaced operators and keywords.Still differing on
main: the update expression structure checks (duplicate sections, overlapping paths, nested functions), theRequested resource not found: Table: <name> not foundtext, GetItem with a wrong key type answering the PutItem text, the1 validation error detected:prefix on UpdateItem and PutItem expression errors, and the operand and function placement messages. The TransactGetItems and TransactWriteItems validation order rows were not traced here; #399 changes that order.navareamol commentedon Oct 29, 2026
This is already fixed.
fix(expressions): validate requests in the service's order and with i…