BatchWriteItem, TransactWriteItems and other operations store N values that fail number validation as written
I maintainer di solito rispondono entro 2 giorni
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Summary
Only PutItem (the item) and UpdateItem (ExpressionAttributeValues and AttributeUpdates) run number validation. AttributeValue's Deserialize keeps an N value that fails validation as its raw string (crates/core/src/types/attribute_value.rs:105-108), so the validation layer can refuse it later. The other operations do not refuse it with a ValidationException: BatchWriteItem and TransactWriteItems store {"N": "abc"} and {"N": "1E126"} as written, where Amazon DynamoDB answers ValidationException, and answer InternalServerError (HTTP 500) when such a value is an N sort key that does not parse as a decimal.
Measured (2026-10-27 09:35 to 10:05 UTC, each request sent twice, both rounds the same)
Non-key attribute n on a table with string keys:
| Request | DynamoDB (us-east-1) | ExtendDB main abf8082f, SQLite, debug build |
|---|---|---|
BatchWriteItem put, n = abc |
ValidationException The parameter cannot be converted to a numeric value: abc |
200, GetItem returns n = abc |
BatchWriteItem put, n = 1E126 |
ValidationException Number overflow. Attempting to store a number with magnitude larger than supported range |
200, GetItem returns n = 1E126 |
TransactWriteItems put, n = abc |
ValidationException The parameter cannot be converted to a numeric value: abc |
200, GetItem returns n = abc |
TransactWriteItems put, n = 1E126 |
ValidationException Number overflow. Attempting to store a number with magnitude larger than supported range |
200, GetItem returns n = 1E126 |
BatchWriteItem put, n = 10E2147483647 |
ValidationException Number underflow. Attempting to store a number with magnitude smaller than supported range |
connection closed (#616) |
On these two operations DynamoDB's messages carry no 1 validation error detected: prefix, where its PutItem messages do. Its BatchWriteItem answers Number underflow for 10E2147483647, where its PutItem answers Number overflow for the same value. The expected text has to be measured per operation.
An N sort key abc through BatchWriteItem or TransactWriteItems answers InternalServerError on ExtendDB, and the server logs invalid numeric sort key: invalid digit found in string. DynamoDB's answer to that request was not measured.
Where validation is missing
From reading the code, not measured: number validation runs in validate_put_item and validate_update_item (crates/core/src/validation/mod.rs) only. It does not run for BatchWriteItem, TransactWriteItems, the keys of GetItem, BatchGetItem, TransactGetItems, DeleteItem and UpdateItem, Query and Scan expression values, PutItem and DeleteItem expression values, or ImportTable items. Open PRs #544 and #562 add the check for Query and Scan expression values.
An N partition key is stored as its text (pk_to_text, crates/storage/src/util/key.rs:78), so a key such as 1E126 written through BatchWriteItem becomes a partition of its own. extract_typed_value in crates/server/src/leading_keys.rs returns no dynamodb:LeadingKeys value for an N key that fails validation, on the assumption that the engine then refuses the request. On the operations above it does not. I did not test this under an IAM policy.
Zeros with an out-of-range exponent
DynamoDB range checks a zero on its exponent less its fraction digits: 0E125 and 0.0E126 are accepted, 0E126 is Number overflow and 0.0E-130 is Number underflow (measured with PutItem, 2026-10-27). With the #616 fix, ExtendDB accepts every zero whose exponent fits in an i32 as 0. That check cannot be added before this issue is fixed: a zero it refused would keep its raw spelling, and the operations above would then store and look up 0E126 as a key separate from 0. The fix for #616 leaves those zeros accepted for that reason, and a unit test there marks the place to change.
- Lingua principale
- Rust
- Stelle
- 517
- Fork
- 60
- Merge medio
- 2g 22h
- PR unite (30g)
- 25
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ExtendDB/extenddb
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 2 giorni
-
backend:mongodb bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
I maintainer di solito rispondono entro 2 giorni
-
backend:cassandra bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 2 giorni
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 2 giorni
-
backend:cassandra bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di ExtendDB/extenddb
Issue simili
-
area: library data-loss type: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
alplabai/signex#1740 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
test(fslc): the unreadable mutate catalog test pins the Unix I/O error text and fails on WindowsForse già presa @rizumita l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 69/100
I maintainer di solito rispondono entro 1 giorno
-
ServerProperties defaults white-list to true, so a fresh --dedicated server silently locks itselfAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
horizon-rust/horizon#3888 ·
I maintainer di solito rispondono entro 1 giorno
-
refactor
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno