A repeated type descriptor in an attribute value is accepted last-wins where the service refuses it
Los mantenedores suelen responder en 4 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 54/100
Línea de trabajo
Start by tracing how item-carrying requests parse the raw body into serde_json::Value, and inspect the existing duplicate check for TransactWriteItems members. Compare that path with AttributeValue deserialization to find where repeated keys are lost. Done means duplicate type descriptors and item attribute names are rejected with the service’s 400 SerializationException response across the listed operations, including nested values.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
An attribute value object that names the same type descriptor twice, for example {"S": "a", "S": "b"}, at the top level of a value or inside an L or an M, is refused by the service with 400 SerializationException and the message Duplicate key found in payload. Measured on 2026-10-28 in us-east-1 on PutItem, UpdateItem, TransactWriteItems and BatchWriteItem, two repetitions each; the same answer in every cell.
ExtendDB at abf8082f answers 200 on all four operations and stores the last value (b), top-level and nested (SQLite server, two repetitions). The bytes a client sent have one reading on the service (refused) and another in ExtendDB (the last descriptor wins), and a request that the service would never have stored is written.
Where: the request body is parsed into serde_json::Value before the AttributeValue deserializer runs, and serde_json's map collapses a repeated key. Refusing the repeated key needs either the raw-body duplicate check that TransactWriteItems already applies to its own members, or a Value parse with duplicate detection, applied to every item-carrying request. A repeated attribute name at the item level ({"a": ..., "a": ...}) is the same class and the same message on the service.
- Lenguaje dominante
- Rust
- Estrellas
- 517
- Forks
- 60
- Merge medio
- 4 d 10 h
- PR fusionados (30 d)
- 37
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ExtendDB/extenddb
-
Dificultad 2/5 3-5 días Aptitud para principiantes 65/100
Los mantenedores suelen responder en 4 días
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
ExtendDB/extenddb#658 · 1 comentario ·
Los mantenedores suelen responder en 4 días
-
backend:postgresql bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 4 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 4 días
-
backend:mongodb bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
Los mantenedores suelen responder en 4 días
Todos los issues de ExtendDB/extenddb
Issues similares
-
ai_p2 bug comp-datalake
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
ClickHouse/ClickHouse#128306 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
bug triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
Remove the preset version numberAbiertoarea: ui enhancement good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
JavenKazebee/capture-room#166 ·
Los mantenedores suelen responder en 1 día