Repository navigation
Conversation
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9b41d01d9d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| unsigned char framed[] = { | ||
| FLB_SNAPPY_FRAME_TYPE_STREAM_IDENTIFIER, 6, 0, 0, 's', 'N', 'a', 'P', 'p', 'Y', | ||
| FLB_SNAPPY_FRAME_TYPE_UNCOMPRESSED_DATA, 7, 0, 0, | ||
| 0x6e, 0x57, 0xf1, 0x21, 'a', 'b', 'c', |
There was a problem hiding this comment.
Decode framed checksums as little-endian before this test
On the big-endian s390x entry in .github/workflows/unit-tests.yaml:277-280 (which runs all internal CTests at lines 324-336), the first new success case cannot pass: flb_snappy_uncompress_framed_data() loads frame_checksum through native-endian uint32_t dereferences at src/flb_snappy.c:223 and src/flb_snappy.c:270, so the wire bytes 6e 57 f1 21 are seen as 0x6e57f121 instead of 0x21f1576e. This makes flb-it-compression fail in that matrix; decode the checksum with an unaligned-safe little-endian read.
Useful? React with 👍 / 👎.
| } | ||
| else { | ||
| if (aggregated_data_length > 0) { | ||
| if (result == 0 && aggregated_data_length > 0) { |
There was a problem hiding this comment.
Reject streams that never supplied a valid Snappy identifier
When an HTTP body starts with a 0xff chunk whose length is not 6 (for example ff 00 00 00) and then carries a checksum-valid uncompressed JSON chunk, the identifier branch at src/flb_snappy.c:190-202 leaves both result == 0 and stream_identifier_found == false. This newly enabled allocation therefore copies and returns the JSON, so the HTTP input forwards a stream that never contained the required sNaPpY identifier; before this change the reset made this slow path yield zero bytes. Reject this state before either output path and cover it as an invalid envelope.
AGENTS.md reference: AGENTS.md:L120-L120
Useful? React with 👍 / 👎.
Signed-off-by: Tyler Coatsworth <14064505+tcoatswo@users.noreply.github.com>
Signed-off-by: Tyler Coatsworth <14064505+tcoatswo@users.noreply.github.com>
9b41d01 to
464dc93
Compare
|
Rebased onto |
Summary
Upstream has implemented bounded Snappy decoding (
flb_snappy_uncompress_bounded) via commit 8b100a5. This PR has been rebased on upstream/master to drop the superseded changes insrc/flb_snappy.cwhile retaining test coverage for multi-chunk / uncompressed framed Snappy chunk aggregation and HTTP ingestion.Changes
tests/internal/compression.c): Addedtest_snappy_framed_aggregationto test single uncompressed, multiple uncompressed, single compressed, mixed compressed/uncompressed, and corrupted checksum framed chunks againstflb_snappy_uncompress_framed_data.tests/integration/scenarios/in_http/tests/test_in_http_001.py): Addedtest_snappy_framed_uncompressed_dataparameterized for single and multiple chunk framed Snappy ingestion over HTTP.Fluent Bit is licensed under Apache 2.0; by submitting this pull request I understand that this code will be released under that license.
Summary by CodeRabbit