Node SDK: send accepts malformed user headers that fail during polling
Los mantenedores suelen responder en 1 día
Evaluación
Este issue todavía no se ha evaluado.
Descripción
Bug description
The Node SDK accepts malformed user headers when sending messages, but polling those messages fails to decode them.
Confirmed cases:
- Empty raw header value.
- String value longer than 255 bytes.
- Int128 value containing only one byte instead of 16.
- Empty string key.
Each send receives a confirmation at offset 0. Polling then fails with “user headers of the message at offset 0 do not decode.” A valid string header sends and polls successfully.
The encoder should reject these invalid headers before sending. Confirmed against a real server using SDK and server revision 7b053f4cbf635d03ba187123a42c0157ac554587.
Related fixes #4481 (Go) and #4670 (HTTP) do not cover the Node encoder. I would like to contribute a regression test first and discuss the fix approach.
Affected area / component
Node.js SDK
Deployment
Docker (DockerHub image)
Versions
SDK and server revision: 7b053f4cbf635d03ba187123a42c0157ac554587
Server image: apache/iggy:edge
Image digest: sha256:3dba2cd7b16e0362112ae248507b4a7b2eb27593332c6421386011fb1795975d
Hardware / environment
macOS, Node.js v24.4.1, fresh single-node Iggy server in Docker. Tested using the upstream Node SDK over TCP, with isolated container storage.
Sample code
const headers = [{
key: HeaderKeyFactory.String('key'),
value: HeaderValue.Raw(Buffer.alloc(0))
}];
const result = await client.message.send({
streamId,
topicId,
partition: Partitioning.PartitionId(0),
messages: [{ id: 1n, payload: 'repro', headers }]
});
// Send succeeds with a confirmation at offset 0.
await client.message.poll({
streamId,
topicId,
consumer: Consumer.Single,
partitionId: 0,
pollingStrategy: PollingStrategy.First,
count: 1,
autocommit: false
});
// Fails to decode the stored message's headers.
Logs
valid: SEND CONFIRMED offset=0
valid: POLL SUCCEEDED
empty-value: SEND CONFIRMED offset=0
empty-value: POLL FAILED user headers of the message at offset 0 do not decode; cause=Invalid header value length: 0, must be between 1 and 255
Iggy server config
Fresh single-node server with development credentials.
IGGY_HTTP_ADDRESS=0.0.0.0:3000
IGGY_TCP_ADDRESS=0.0.0.0:38090
IGGY_NODE_ADVERTISED_ADDRESS=localhost
TCP port 38090 was published to localhost. No custom persistence settings.
Reproduction
- Start a fresh Iggy server and connect using the Node SDK.
- Create a stream and a topic with one partition.
- Send a message containing a string header key and an empty raw header value, as shown above.
- The send succeeds and confirms offset 0.
- Poll the topic from the first offset.
- Polling fails because the header value length is 0.
Also reproduced with:
- HeaderValue.String('a'.repeat(256))
- HeaderValue.Int128(Buffer.from([1]))
- HeaderKeyFactory.String('') with a nonempty value
A normal nonempty string key and value send and poll successfully.
Contribution
- I'm willing to submit a pull request to fix this bug
Good first issue
- I think this could be a good first issue for a new contributor
- Lenguaje dominante
- Rust
- Estrellas
- 5.2k
- Forks
- 516
- Merge medio
- 2 d 21 h
- PR fusionados (30 d)
- 159
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- 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 apache/iggy
-
Go examples: add a message envelope producer and consumerPosiblemente ocupada @ThunderGod77 la tomó hace 5 días. Abiertogo good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
apache/iggy#4694 · 3 comentarios · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
HTTP client treats a consumer group as a plain consumerPosiblemente ocupada @mohitduhan19 la tomó hace 23 días. Abiertobug rust server
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
apache/iggy#4408 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Add the fail-fast connection option to the Rust and Python quick-startsPosiblemente ocupada @QIW9 la tomó hace 10 días. Abiertodocs good first issue
Dificultad 1/5 1-3 horas Aptitud para principiantes 92/100
apache/iggy#4261 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
ResourceNotFound from the binary protocol prints an empty keyPosiblemente ocupada @xalestar la tomó hace 2 días. Abiertoapi python rust
apache/iggy#4767 · 2 comentarios · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Go SDK: validate personal access token name length before serializationPosiblemente ocupada @p4rtridge la tomó hace 3 días. Abiertobug go good first issue
apache/iggy#4749 · 1 asignado ·
Los mantenedores suelen responder en 1 día
Todos los issues de apache/iggy
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
rubys/roundhouse#1917 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 2 días
-
good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
[cosmic-applet-battery] Division by zero displays NaN% when UPower reports max_brightness = 0Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
pop-os/cosmic-applets#1619 ·
Los mantenedores suelen responder en 3 días
-
binding:python bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día