in_forward: fix stale byte accounting when multiple frames share a buffer#12049
in_forward: fix stale byte accounting when multiple frames share a buffer#12049zshuang0316 wants to merge 1 commit into
Conversation
…ffer The frame loop advances to the next object with the plain msgpack_unpacker_next(), which does not refresh 'bytes'. When several frames arrive in a single buffer (common with compressed payloads, which are small), iterations after the first add the previous object's stale size to 'all_used'. That wrong total trims conn->buf by the wrong offset and desyncs the remaining frames. Use msgpack_unpacker_next_with_size() so 'bytes' is refreshed for every object, matching the initial parse. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: zshuang0316 <zshuang0316@163.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughA single-line fix in the forward input plugin's msgpack parsing loop switches from ChangesMsgpack Unpacking Fix
Estimated code review effort: 1 (Trivial) | ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@codex review |
|
Codex Review: Didn't find any major issues. Already looking forward to the next diff. Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
Summary
In
fw_prot_process, the inner frame loop tracks how many bytes each decoded object consumed inall_used, then uses it to trimconn->bufonce the buffer is drained. The first object is parsed withmsgpack_unpacker_next_with_size(unp, &result, &bytes), but the loop tail advanced to the next object with the plainmsgpack_unpacker_next(unp, &result), which does not refreshbytes.When several frames arrive in a single buffer — common with compressed payloads, which are small — every iteration after the first adds the previous object's stale
bytestoall_used. The resulting total is wrong, soconn->bufis trimmed by the wrong offset and the remaining frames in the buffer desync.The fix uses
msgpack_unpacker_next_with_size()at the loop tail as well, sobytesis refreshed for every object, matching the initial parse.Enter
[N/A]in the box, if an item is not applicable to your change.Testing
Before we can approve your change; please submit the following in a comment:
If this is a change to packaging of containers or native binaries then please confirm it works for all targets.
ok-package-testlabel to test for all targets (requires maintainer to do).Documentation
Backporting
Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.
Summary by CodeRabbit