Repository navigation
Conversation
KafkaRecordSchema decoded each header value with
String.fromCodePoint(...value), which throws a RangeError that escapes
safeParse. Lambda sends header bytes as signed Java bytes, so any byte
>= 128 arrives negative and every real event with a non-ASCII or binary
header failed to parse. Spreading the array also exceeded the call stack
for large headers.
Validate header values as integers from -128 to 255, so out-of-range
values become Zod issues, and decode with Buffer.from(value).toString('utf8'),
which masks each number to a byte, has no argument limit, and matches how
@aws-lambda-powertools/kafka decodes headers.
Add a record with a signed UTF-8 header to the Kafka test event, matching
the one Powertools for Python added, and cover out-of-range values and a
large header.
Closes aws-powertools#5830
svozza
approved these changes
Oct 24, 2026
Contributor
|
Nice. Merged! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
KafkaRecordSchemadecoded each header value withString.fromCodePoint(...value), which throws aRangeErrorthat escapessafeParse. Lambda sends header bytes as signed Java bytes, so any byte of 128 or above arrives negative, and every real event with a non-ASCII or binary header failed to parse. Spreading the array also exceeded the call stack for large headers. This validates header values as bytes and decodes them without spreading.Changes
packages/parser/src/schemas/kafka.tswithz.array(z.number().int().min(-128).max(255)), accepting Lambda's signed form and unsigned hand-written values, so out-of-range values become Zod issues instead of a thrownRangeError.Buffer.from(value).toString('utf8').Buffer.frommasks each number to a byte, so negative values convert, and there is no argument-count limit. This matches how@aws-lambda-powertools/kafkadecodes headers inpackages/kafka/src/consumer.ts. ASCII headers decode exactly as before.packages/parser/tests/events/kafka/base.json, and updated the schema and envelope tests to expect it decoded ashello-world-ë. Against the schema onmain, the record makes nine existing Kafka tests fail with aRangeError.-129,256,1.5), which return an issue fromsafeParse, and for a 200,000-byte header, which decodes without exceeding the call stack.The Python record has
"key": null, which our schema rejects, sincekeyis an optional string. I leftkeyout of the added record so the test stays about headers. Whether real events can send a null key is a separate question.Issue number: closes #5830
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.