k/generator: do not use standard vectors for offset commit protocol #26280
Conversation
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
Implementation of `then()` uses a `std::forward<Func>` when creating continuation. Passing in an lvalue ref to `fut.then(...)` forces the copy. Replaced it with lambda capturing the reference to `func` not to have to copy the whole `func` Signed-off-by: Michał Maślanka <michal@redpanda.com>
ca99c81 to
dc94b03
Compare
Retry command for Build#66564please wait until all jobs are finished before running the slash command |
CI test resultstest results on build#66564
|
In transactional and standard offset commit request and replies topic partition offsets are stored as a vectors. The number of partitions/topics in a single request may grow large, therefore we should use a fragmented vector when handling those requests. Changed the Kafka protocol generator overrides for offset commit requests and responses to use default `chunked_vector` Signed-off-by: Michał Maślanka <michal@redpanda.com>
dc94b03 to
50cf97b
Compare
dotnwat
reviewed
May 29, 2025
Comment on lines
-71
to
+72
| return fut.then(func).handle_exception( | ||
| [&eptr](std::exception_ptr ex) mutable { | ||
| return fut.then([&func] { return func(); }) | ||
| .handle_exception([&eptr](std::exception_ptr ex) mutable { |
There was a problem hiding this comment.
this looks ok, but i'm having trouble determining if this is safe w.r.t. to guarnateeing that the retry function will always execute with a fresh version of it's original captures. i think that is true if func is the user provided function, but i'm less sure that is true for gated_retry_with_mitigation_impl which wraps the user function and how the const-ness of operator()() propogates to the captured function.
maybe @BenPope knows. i've seen this exact function have similar proposals made recently and I'm not sure where things stand with those changes and if there are footguns here.
--
more broadly, though, and not necessarily blocking this PR: do we want to optimize for large captures? it seems like the caller could always arrange for a large object to be captured as a reference, shared pointer, etc...?
There was a problem hiding this comment.
the static assert pass, i.e. it should not be possible to do std::move() in the body of operator()() of the func
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.
In transactional and standard offset commit request and replies topic partition offsets are stored as a vectors. The number of partitions/topics in a single request may grow large, therefore we should use a fragmented vector when handling those requests.
Changed the Kafka protocol generator overrides for offset commit requests and responses to use default
chunked_vectorBackports Required
Release Notes
Improvements