jsancio opened a new pull request, #22505: URL: https://github.com/apache/kafka/pull/22505
This is an internal refactoring with no changes to external behavior or wire protocol. The current KRaft API embeds CompletableFuture fields directly in RaftRequest and RaftResponse objects via the completion field. This design has several drawbacks. First, it creates API clarity issues because requests and responses are data carriers, but the embedded future makes them also responsible for asynchronous completion signaling. Second, it creates ownership confusion about who owns the lifecycle of the embedded future. Third, it reduces type safety because the completion future is exposed as a mutable field, allowing external code to complete it incorrectly. This PR refactors the message handling API to return CompletionStage from methods instead of embedding futures in data objects. The RaftMessageQueue now uses a QueueEntry wrapper class that pairs a RaftMessage with its CompletableFuture<RaftMessage>. The poll() method returns Optional<QueueEntry> instead of nullable RaftMessage, and the add() method accepts QueueEntry instead of RaftMessage. The NetworkChannel interface changed send(RaftRequest.Outbound) from void to CompletionStage<RaftResponse.Inbound>, and the completion field was removed from RaftRequest. The KafkaRaftClient changed handle(RaftRequest.Inbound) from void to CompletionStage<RaftResponse.Outbound>. Request handling now creates the QueueEntry, adds it to the message queue, and returns its future. Response completion is managed internally by the queue system. The RaftManager interface changed handleRequest() return type to CompletionStage<ApiMessage> from CompletableFuture<ApiMessage>. Callers convert to CompletableFuture only when needed via toCompletableFuture. This refactoring provides several benefits. The asynchronous behavior is now explicit in method signatures, creating a cleaner API. Messages are pure data with completion handled by the API methods, improving separation of concerns. Type safety is improved because futures are returned from methods rather than exposed as mutable fields. The design now follows standard Java patterns by using CompletionStage in interfaces and CompletableFuture in implementations. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
