Skip to content

fix: validation error messages match DynamoDB format - #16

Merged
pdf-amzn merged 1 commit into
mainfrom
fix/validation-message-format
May 15, 2026
Merged

fix: validation error messages match DynamoDB format#16
pdf-amzn merged 1 commit into
mainfrom
fix/validation-message-format

Conversation

@LeeroyHannigan

Copy link
Copy Markdown
Collaborator

Summary

Validation error messages now match DynamoDB's exact format. Conformance suite improves from 467/576 (81.1%) to 479/576 (83.2%).

Changes

Formatter functions: Added validation_error(value, field, constraint) and validation_errors(errors) in
crates/core/src/error/messages.rs that produce DynamoDB's exact format: "1 validation error detected: Value '{value}' at '{field}' failed to satisfy constraint: {constraint}".

Table name validation: Split too-short/too-long into separate checks that include the actual value and field path in the message.

KeySchema validation: >2 elements now serializes the array in KeySchemaElement(attributeName=..., keyType=...) format matching DynamoDB's Java toString output.

TransactGetItems/TransactWriteItems: Empty list returns "Value '[]'" with "greater than or equal to 1" constraint. Exceeding 100 items includes the serialized list value.

BatchGetItem: Per-table >100 keys check added with correct field path "RequestItems.{table}.member.Keys".

BatchWriteItem: >25 items includes the map value representation matching DynamoDB's format.

Testing

  • cargo test --workspace all pass
  • Conformance suite 479/576 (83.2%), 12 new passes, 0 regressions

Files changed (7)

  • crates/core/src/error/messages.rsvalidation_error(), validation_errors() formatters
  • crates/core/src/error/mod.rs — export new functions
  • crates/core/src/validation/mod.rs — table name + key schema messages, format_key_schema_value helper
  • crates/engine/src/batch_get_item.rs — per-table key count check with correct message
  • crates/engine/src/batch_write_item.rs — >25 items message with map value
  • crates/engine/src/transact_get_items.rs — empty/too-many messages
  • crates/engine/src/transact_write_items.rs — empty/too-many messages

- Add validation_error()/validation_errors() formatter functions
- Table name: length errors include value and field path
- KeySchema: >2 elements includes serialized array value
- TransactGetItems/TransactWriteItems: empty/too-many use correct format
- BatchGetItem: per-table >100 keys uses correct field path
- BatchWriteItem: >25 items includes map value representation
@pdf-amzn
pdf-amzn merged commit 736e82f into mainMay 15, 2026
LeeroyHannigan added a commit that referenced this pull request Aug 18, 2026
CodeQL (actions/cache-poisoning/poisonable-step) flags writing the default
branch's actions cache from a job that checks out a dispatch-resolved SHA.
The gate proves that SHA is an ancestor of origin/main, so the checkout is
reviewed history, but the cache write is still the one genuine poisoning
vector the rule describes, and it buys little on a rare release build that
the LTO link dominates. Removed.
The remaining alert on the gate job has no cache usage at all and mirrors
the two open alerts on release-image.yml (#16, #17): the rule matches any
checkout-and-execute of a resolved SHA under workflow_dispatch.
LeeroyHannigan added a commit that referenced this pull request Aug 19, 2026
CodeQL (actions/cache-poisoning/poisonable-step) flags writing the default
branch's actions cache from a job that checks out a dispatch-resolved SHA.
The gate proves that SHA is an ancestor of origin/main, so the checkout is
reviewed history, but the cache write is still the one genuine poisoning
vector the rule describes, and it buys little on a rare release build that
the LTO link dominates. Removed.
The remaining alert on the gate job has no cache usage at all and mirrors
the two open alerts on release-image.yml (#16, #17): the rule matches any
checkout-and-execute of a resolved SHA under workflow_dispatch.
rlunar pushed a commit to rlunar/extenddb that referenced this pull request Aug 20, 2026
CodeQL (actions/cache-poisoning/poisonable-step) flags writing the default
branch's actions cache from a job that checks out a dispatch-resolved SHA.
The gate proves that SHA is an ancestor of origin/main, so the checkout is
reviewed history, but the cache write is still the one genuine poisoning
vector the rule describes, and it buys little on a rare release build that
the LTO link dominates. Removed.
The remaining alert on the gate job has no cache usage at all and mirrors
the two open alerts on release-image.yml (ExtendDB#16, ExtendDB#17): the rule matches any
checkout-and-execute of a resolved SHA under workflow_dispatch.
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@LeeroyHannigan@jcshepherd@pdf-amzn