KAFKA-10551: Add topic id support to produce request and response #15968

OmniaGM · 2024-05-15T15:53:10Z

Add support topicId in ProduceRequest/ProduceResponse. Topic name
and Topic Id will become ignorable following the footstep of
FetchRequest/FetchResponse
ReplicaManager still look for HostedPartition using TopicPartition
and doesn't check topic id. This is an [OPEN QUESTION] if we should
address this in this pr or wait for
KAFKA-16212 as this
will update ReplicaManager::getPartition to use TopicIdParittion
once we update the cache. Other option is that we compare provided
topicId with Partition topic id and return UNKNOW_TOPIC_ID or
UNKNOW_TOPIC_PARTITION if we can't find partition with matched topic
id.

Reviewers: Jun Rao [email protected], Justine Olshan
[email protected]

…equest

OmniaGM · 2024-05-16T13:01:33Z

Few of the failed tests are related to this change and am working on fixing them

OmniaGM · 2024-05-20T12:00:14Z

Few of the failed tests are related to this change and am working on fixing them

I believe that failed tests now are unrelated

jolshan · 2024-05-20T22:29:30Z

Topic name and Topic Id will become optional following the footstep of FetchRequest/FetchResponse

My understanding is that all requests going forward will use ID and not name similar to fetch request. I believe that is what is in the PR, but the comment suggests otherwise.

jolshan · 2024-05-20T22:41:11Z

clients/src/main/java/org/apache/kafka/clients/producer/internals/Sender.java

@@ -610,7 +611,9 @@ private void handleProduceResponse(ClientResponse response, Map<TopicPartition,
                // This will be set by completeBatch.
                Map<TopicPartition, Metadata.LeaderIdAndEpoch> partitionsWithUpdatedLeaderInfo = new HashMap<>();
                produceResponse.data().responses().forEach(r -> r.partitionResponses().forEach(p -> {
-                    TopicPartition tp = new TopicPartition(r.name(), p.index());
+                    // Version 12 drop topic name and add support to topic id. However, metadata can be used to map topic id to topic name.
+                    String topicName = (r.name() == null || r.name().isEmpty()) ? metadata.topicNames().get(r.topicId()) : r.name();


What do we do if metadata has refreshed and is no longer in the metadata?
For fetch it is a bit different since we have the session logic, and can handle missing topics.

I would recommend writing through a few cases where the server and client have/don't have the topic ID to reason about the upgrade case/downgrade case/deletions/reassignments.

If topic has been recreated and topic id is out of date, the client will get UNKNOWN_TOPIC_ID and on the retry the topic id will be updated

If topic has been reassigned to another broker then the client will get NOT_LEADER_OR_FOLLOWER and then the client can retry with the right broker.

Am not sure what upgrade case/downgrade you refer too here Do you mean the client and broker IBP combination? If yes then some of these are covered in ProduceRequestTest and RequestResponseTest

I added two test cases to cover the first two and the producer seem to self recover on retry.

Yes. For the fetch request for example, there is code to make sure that all topics have IDs before we can send the fetch request. This is a bit less of an issue now, but if we have a cluster that is running on a MV < 2.8, topics will not have IDs. So when we decide which version of produce we want to send, we want to be aware of this.

Not only that, but even if the broker supports topic IDs on all topics, we also may have a case where we need to do a rolling upgrade to get the code that supports handling the latest API version. This may be less complicated for Produce since it is a client only API and doesn't rely on MV/IBP, so the apiVersions exchange between the client and the broker may be enough to ensure api compatibility.

We just want to confirm these upgrade paths are compatible since produce is the hot path and we don't want any (or at least not extended) downtime in the middle of an upgrade.

Hi @jolshan sorry for taking too long to get back to you on this. I have added ApiVersions::maxSupportedProduceVersion to determine what the supported version supported on the cluster. Regarding the tests for these combination of old/new producer with old/new broker are all covered in the system tests tests/kafkatest/tests/core/compatibility_test_new_broker_test.py and tests/kafkatest/tests/client/client_compatibility_produce_consume_test.py. I am trying to add another one to test the same while deleting topic and leadership changes but not sure if we really need to cover this or not as these are covered in the integration tests. WDYT?

No problem. I've also been super busy so not sure if I would have had time to review.

As long as the tests are between an older version and a newer version (ie not upgrade tests where the issue can just seem transient) then this should be ok.

Whenever I implemented the fetch change, I also did some sanity checks by looking at the logs when upgrading to see the change in request version without errors. I'd recommend doing this at least once as a manual test.

Thanks for the change and I will take a look.

clients/src/main/java/org/apache/kafka/clients/producer/internals/Sender.java

core/src/main/scala/kafka/server/KafkaApis.scala

jolshan · 2024-05-20T23:10:47Z

core/src/main/scala/kafka/server/ReplicaManager.scala

@@ -1361,10 +1366,10 @@ class ReplicaManager(val config: KafkaConfig,
   */
  private def appendToLocalLog(internalTopicsAllowed: Boolean,
                               origin: AppendOrigin,
-                               entriesPerPartition: Map[TopicPartition, MemoryRecords],
+                               entriesPerPartition: Map[TopicIdPartition, MemoryRecords],


is there a reason to pass this data structure here if we are not using the ID to check the append at the log level?

two reasons here

I didn't want to keep convert between TopicIdPartitions to TopicPartition

KAFKA-16212 will eventually use TopicIdPartitions to getPartitionOrException

Ok -- once we start using these across the log layer it makes sense.

Did we end up doing the getPartitionOrException in this PR?

We introduced getPartitionOrException(topicIdPartition: TopicIdPartition) that verifies the topicId if provided.

jolshan · 2024-05-20T23:31:21Z

I would recommend taking a look at where we are passing the topic ID through and the checks we do. If we think it is useful to ensure we are writing to the right topic, we should do it, but if it is just adding complexity, we may want to consider changing.

OmniaGM · 2024-05-22T09:42:02Z

Topic name and Topic Id will become optional following the footstep of FetchRequest/FetchResponse

My understanding is that all requests going forward will use ID and not name similar to fetch request. I believe that is what is in the PR, but the comment suggests otherwise.

I meant that in Json files both will be marked ignorable

…equest

junrao

@OmniaGM : Thanks for the updated PR. A few more comments.

core/src/test/scala/unit/kafka/server/ProduceRequestTest.scala

clients/src/test/java/org/apache/kafka/common/requests/ProduceRequestTest.java

jolshan

Thanks Omnia for your hard work!

junrao

@OmniaGM : Thanks for the updated PR. A couple of more comments.

clients/src/test/java/org/apache/kafka/common/requests/ProduceRequestTest.java

junrao

@OmniaGM : Thanks for the updated PR. One more comment. Also, could you rebase?

clients/src/test/java/org/apache/kafka/common/requests/ProduceRequestTest.java

…equest

junrao

@OmniaGM : Thanks for the updated PR. The code LGTM. Is the test failure PlaintextConsumerTest related? If not, perhaps you could rebase to trigger another run of the test.

jolshan · 2025-04-29T18:35:18Z

I triggered the rerun 👍

jolshan · 2025-04-29T21:58:29Z

@junrao build is green now! I noticed you didn't hit the approve button on GH, so I will wait to merge just to double check.

junrao

@OmniaGM : Thanks for addressing all the comments. LGTM

@jolshan : Feel free to merge it.

OmniaGM · 2025-04-30T10:47:32Z

@OmniaGM : Thanks for addressing all the comments. LGTM

@jolshan : Feel free to merge it.

Thanks for reviewing this and merging. It is finally merged before hitting exactly 1 year :D

junrao · 2025-05-02T20:45:56Z

core/src/main/scala/kafka/server/KafkaApis.scala

+        if (topicName.isEmpty)
+          nonExistingTopicResponses += new TopicIdPartition(topicId, topicPartition) -> new PartitionResponse(Errors.UNKNOWN_TOPIC_ID)
+        else if (!metadataCache.contains(topicPartition))
+          nonExistingTopicResponses += new TopicIdPartition(topicId, topicPartition) -> new PartitionResponse(Errors.UNKNOWN_TOPIC_OR_PARTITION)


This seems to be a regression. Since topic name is sensitive, if the topic name doesn't exist and is not authorized, we should return TOPIC_AUTHORIZATION_FAILED, instead of UNKNOWN_TOPIC_OR_PARTITION. Filed https://issues.apache.org/jira/browse/KAFKA-19234 to track it.

Hmm -- I recall some discussion around this for fetch requests...Is it different for produce?

KAFKA-12394

Its funny because you can re-arrange the numbers to get the jira number 😂

I also see that this is a slightly different case, so makes sense. 👍

It seems that the Fetch request does the right thing. If an old version of the fetch request includes topic name that doesn't exist, it will go through the authorization check first.

// Regular Kafka consumers need READ permission on each partition they are fetching. val partitionDatas = new mutable.ArrayBuffer[(TopicIdPartition, FetchRequest.PartitionData)] fetchContext.foreachPartition { (topicIdPartition, partitionData) => if (topicIdPartition.topic == null) erroneous += topicIdPartition -> FetchResponse.partitionResponse(topicIdPartition, Errors.UNKNOWN_TOPIC_ID) else partitionDatas += topicIdPartition -> partitionData } val authorizedTopics = authHelper.filterByAuthorized(request.context, READ, TOPIC, partitionDatas)(_._1.topicPartition.topic) partitionDatas.foreach { case (topicIdPartition, data) => if (!authorizedTopics.contains(topicIdPartition.topic)) erroneous += topicIdPartition -> FetchResponse.partitionResponse(topicIdPartition, Errors.TOPIC_AUTHORIZATION_FAILED) else if (!metadataCache.contains(topicIdPartition.topicPartition)) erroneous += topicIdPartition -> FetchResponse.partitionResponse(topicIdPartition, Errors.UNKNOWN_TOPIC_OR_PARTITION)

…ache#15968) - Add support topicId in `ProduceRequest`/`ProduceResponse`. Topic name and Topic Id will become `ignorable` following the footstep of `FetchRequest`/`FetchResponse` - ReplicaManager still look for `HostedPartition` using `TopicPartition` and doesn't check topic id. This is an **[OPEN QUESTION]** if we should address this in this pr or wait for [KAFKA-16212](https://issues.apache.org/jira/browse/KAFKA-16212) as this will update `ReplicaManager::getPartition` to use `TopicIdParittion` once we update the cache. Other option is that we compare provided `topicId` with `Partition` topic id and return `UNKNOW_TOPIC_ID` or `UNKNOW_TOPIC_PARTITION` if we can't find partition with matched topic id. Reviewers: Jun Rao <[email protected]>, Justine Olshan <[email protected]>

lucasbru · 2025-06-03T12:42:06Z

@OmniaGM Hey, I detected the following NPE during Kafka Streams soak testing (on trunk):

[2025-05-29 04:06:05,855] ERROR [kafka-producer-network-thread | i-07bbab180f6062ba3-StreamThread-3-producer] [Producer clientId=i-07bbab180f6062ba3-StreamThread-3-producer] Uncaught error in request completion: (org.apache.kafka.clients.NetworkClient)
java.lang.NullPointerException: Cannot read field "topicPartition" because "batch" is null
	at org.apache.kafka.clients.producer.internals.TransactionManager.handleCompletedBatch(TransactionManager.java:748)
	at org.apache.kafka.clients.producer.internals.Sender.completeBatch(Sender.java:736)
	at org.apache.kafka.clients.producer.internals.Sender.completeBatch(Sender.java:710)
	at org.apache.kafka.clients.producer.internals.Sender.lambda$handleProduceResponse$2(Sender.java:613)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at org.apache.kafka.clients.producer.internals.Sender.lambda$handleProduceResponse$3(Sender.java:597)
	at java.base/java.lang.Iterable.forEach(Iterable.java:75)
	at org.apache.kafka.clients.producer.internals.Sender.handleProduceResponse(Sender.java:597)
	at org.apache.kafka.clients.producer.internals.Sender.lambda$sendProduceRequest$9(Sender.java:895)
	at org.apache.kafka.clients.ClientResponse.onComplete(ClientResponse.java:154)
	at org.apache.kafka.clients.NetworkClient.completeResponses(NetworkClient.java:669)
	at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:661)
	at org.apache.kafka.clients.producer.internals.Sender.runOnce(Sender.java:340)
	at org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:242)
	at java.base/java.lang.Thread.run(Thread.java:840)

It seems likely to me that this may be caused by this PR, given the changes in Sender.handleProduceResponse. Could be a race-condition around topic metadata, but I don't understand the details well enough to fix it myself. Could you please take a look?

cc @jolshan

OmniaGM · 2025-06-10T09:34:42Z

@OmniaGM Hey, I detected the following NPE during Kafka Streams soak testing (on trunk):


[2025-05-29 04:06:05,855] ERROR [kafka-producer-network-thread | i-07bbab180f6062ba3-StreamThread-3-producer] [Producer clientId=i-07bbab180f6062ba3-StreamThread-3-producer] Uncaught error in request completion: (org.apache.kafka.clients.NetworkClient)

java.lang.NullPointerException: Cannot read field "topicPartition" because "batch" is null

	at org.apache.kafka.clients.producer.internals.TransactionManager.handleCompletedBatch(TransactionManager.java:748)

	at org.apache.kafka.clients.producer.internals.Sender.completeBatch(Sender.java:736)

	at org.apache.kafka.clients.producer.internals.Sender.completeBatch(Sender.java:710)

	at org.apache.kafka.clients.producer.internals.Sender.lambda$handleProduceResponse$2(Sender.java:613)

	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)

	at org.apache.kafka.clients.producer.internals.Sender.lambda$handleProduceResponse$3(Sender.java:597)

	at java.base/java.lang.Iterable.forEach(Iterable.java:75)

	at org.apache.kafka.clients.producer.internals.Sender.handleProduceResponse(Sender.java:597)

	at org.apache.kafka.clients.producer.internals.Sender.lambda$sendProduceRequest$9(Sender.java:895)

	at org.apache.kafka.clients.ClientResponse.onComplete(ClientResponse.java:154)

	at org.apache.kafka.clients.NetworkClient.completeResponses(NetworkClient.java:669)

	at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:661)

	at org.apache.kafka.clients.producer.internals.Sender.runOnce(Sender.java:340)

	at org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:242)

	at java.base/java.lang.Thread.run(Thread.java:840)

It seems likely to me that this may be caused by this PR, given the changes in Sender.handleProduceResponse. Could be a race-condition around topic metadata, but I don't understand the details well enough to fix it myself. Could you please take a look?

cc @jolshan

Hi can you please share which test can I run to reproduce this? I will have a look this week.

lucasbru · 2025-06-10T11:59:11Z

@OmniaGM . This is being triggered in a long-running test, so I don't really have a directly reproducable test. However, I have DEBUG logs, which show the METADATA / PRODUCE requests / responses involved, attached to the ticket here:

https://issues.apache.org/jira/browse/KAFKA-19397

This should help with the debugging.

junrao · 2025-06-10T17:36:14Z

@lucasbru : Thanks for reporting this issue. Does the test delete and recreate the same topic?

@OmniaGM : If a topic is recreated with a different topic id while processing a produce response, the following code may not handle it well. topicName will be empty if the topic id has changed in the metadata and batch will be null.

                    // Version 13 drop topic name and add support to topic id. However, metadata can be used to map topic id to topic name.
                    String topicName = metadata.topicNames().getOrDefault(r.topicId(), r.name());
                    TopicPartition tp = new TopicPartition(topicName, p.index());
                    ProduceResponse.PartitionResponse partResp = new ProduceResponse.PartitionResponse(
                            Errors.forCode(p.errorCode()),
                            p.baseOffset(),
                            p.logAppendTimeMs(),
                            p.logStartOffset(),
                            p.recordErrors()
                                .stream()
                                .map(e -> new ProduceResponse.RecordError(e.batchIndex(), e.batchIndexErrorMessage()))
                                .collect(Collectors.toList()),
                            p.errorMessage(),
                            p.currentLeader());
                    ProducerBatch batch = batches.get(tp);

I am wondering if we should include topicId in recordsByPartition in sendProduceRequest(). This way, we don't need to check metadata for topicId since it could change over time.

OmniaGM · 2025-06-10T18:06:47Z

@lucasbru : Thanks for reporting this issue. Does the test delete and recreate the same topic?

@OmniaGM : If a topic is recreated with a different topic id while processing a produce response, the following code may not handle it well. topicName will be empty if the topic id has changed in the metadata and batch will be null.
                    // Version 13 drop topic name and add support to topic id. However, metadata can be used to map topic id to topic name.
                    String topicName = metadata.topicNames().getOrDefault(r.topicId(), r.name());
                    TopicPartition tp = new TopicPartition(topicName, p.index());
                    ProduceResponse.PartitionResponse partResp = new ProduceResponse.PartitionResponse(
                            Errors.forCode(p.errorCode()),
                            p.baseOffset(),
                            p.logAppendTimeMs(),
                            p.logStartOffset(),
                            p.recordErrors()
                                .stream()
                                .map(e -> new ProduceResponse.RecordError(e.batchIndex(), e.batchIndexErrorMessage()))
                                .collect(Collectors.toList()),
                            p.errorMessage(),
                            p.currentLeader());
                    ProducerBatch batch = batches.get(tp);
I am wondering if we should include topicId in recordsByPartition in sendProduceRequest(). This way, we don't need to check metadata for topicId since it could change over time.

This was same thinking I had. Will raise a PR for this

chia7712 · 2025-06-10T18:11:37Z

Does the test delete and recreate the same topic?

I write a rough test according to this comment, and it does reproduce the NPE.

    public void test(ClusterInstance clusterInstance) {
        var topic = "chia";
        var f = CompletableFuture.runAsync(() -> {
            try (var admin = clusterInstance.admin()) {
                for (int i = 1; i <= 1000; i++) {
                    try {
                        admin.deleteTopics(List.of(topic)).all().get();
                    } catch (Exception ignore) {
                    }
                    try {
                        admin.createTopics(List.of(new NewTopic(topic, 10, (short) 1))).all().get();
                    } catch (Exception ignore) {
                    }
                }
            }
        });
        try {
            var fs = IntStream.range(0, 10).mapToObj(ignored -> CompletableFuture.runAsync(() -> {
                try (var producer = clusterInstance.producer()) {
                    for (int i = 1; i <= 1000; i++) {
                        producer.send(new ProducerRecord<>(topic, "value".getBytes()));
                    }
                }
            })).toList();
            fs.forEach(CompletableFuture::join);
        } finally {
            f.join();
        }
    }

[2025-06-11 02:08:07,497] ERROR [Producer clientId=producer-5] Uncaught error in request completion: (org.apache.kafka.clients.NetworkClient:671)
java.lang.NullPointerException: Cannot invoke "org.apache.kafka.clients.producer.internals.ProducerBatch.hasReachedDeliveryTimeout(long, long)" because "batch" is null
	at org.apache.kafka.clients.producer.internals.Sender.canRetry(Sender.java:835) ~[kafka-clients-4.1.0-SNAPSHOT.jar:?]
	at org.apache.kafka.clients.producer.internals.Sender.completeBatch(Sender.java:669) ~[kafka-clients-4.1.0-SNAPSHOT.jar:?]
	at org.apache.kafka.clients.producer.internals.Sender.lambda$handleProduceResponse$2(Sender.java:613) ~[kafka-clients-4.1.0-SNAPSHOT.jar:?]
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) ~[?:?]
	at org.apache.kafka.clients.producer.internals.Sender.lambda$handleProduceResponse$3(Sender.java:597) ~[kafka-clients-4.1.0-SNAPSHOT.jar:?]
	at java.base/java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
	at org.apache.kafka.clients.producer.internals.Sender.handleProduceResponse(Sender.java:597) ~[kafka-clients-4.1.0-SNAPSHOT.jar:?]
	at org.apache.kafka.clients.producer.internals.Sender.lambda$sendProduceRequest$9(Sender.java:895) ~[kafka-clients-4.1.0-SNAPSHOT.jar:?]
	at org.apache.kafka.clients.ClientResponse.onComplete(ClientResponse.java:154) ~[kafka-clients-4.1.0-SNAPSHOT.jar:?]
	at org.apache.kafka.clients.NetworkClient.completeResponses(NetworkClient.java:669) ~[kafka-clients-4.1.0-SNAPSHOT.jar:?]
	at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:661) ~[kafka-clients-4.1.0-SNAPSHOT.jar:?]
	at org.apache.kafka.clients.producer.internals.Sender.runOnce(Sender.java:340) ~[kafka-clients-4.1.0-SNAPSHOT.jar:?]
	at org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:255) ~[kafka-clients-4.1.0-SNAPSHOT.jar:?]
	at java.base/java.lang.Thread.run(Thread.java:1583) [?:?]

lucasbru · 2025-06-11T11:39:22Z

@OmniaGM I don't think the test recreates topics. What I have seen is that sometimes a rebootstrap of the producer happened around the same time. But indeed, if we can avoid the additional lookup in the metadata, this may solve the problem. I can restart the streams soak once your fix is merged, and we should see if the problem reappears.

junrao · 2025-06-11T16:59:25Z

@lucasbru : Thanks for the explanation. During rebootstrap, it's possible that the metadata is empty when an inflight response is being processed. So, this has the same effect of a topic being deleted.

OmniaGM · 2025-06-13T13:47:03Z

I am wondering if we should include topicId in recordsByPartition in sendProduceRequest(). This way, we don't need to check metadata for topicId since it could change over time.

I have been looking into replacing this

String topicName = metadata.topicNames().getOrDefault(r.topicId(), r.name());
                    TopicPartition tp = new TopicPartition(topicName, p.index());

which is used later to batches.get(tp) to the following TopicIdPartition which I will be sending in recordsByPartitioninstead of TopicPartition. The challenge am hitting now is the the response r in this method already doesn't have topic name and only have topic id.

OmniaGM · 2025-06-13T14:39:13Z

I have raised this #19964 pr, trying to update ProducerSendWhileDeletionTest to cover this case better now.

OmniaGM added 4 commits May 8, 2024 14:46

KAFKA-10551: Add topic id support to produce request and response

d3acdf0

KAFKA-10551: fix compatibility with 2.6 IBP

ddeac1b

KAFKA-10551: refactor

a92abe6

Merge remote-tracking branch 'apache/trunk' into KAFKA-10551-produceR…

afede12

…equest

OmniaGM marked this pull request as draft May 15, 2024 15:53

fix test

a8f0c91

OmniaGM force-pushed the KAFKA-10551-produceRequest branch from 1805c4f to a8f0c91 Compare May 15, 2024 22:05

OmniaGM marked this pull request as ready for review May 15, 2024 22:58

OmniaGM changed the title ~~Kafka-10551: Add topic id support to produce request and response~~ KAFKA-10551: Add topic id support to produce request and response May 15, 2024

fix integration tests

8c3602b

OmniaGM force-pushed the KAFKA-10551-produceRequest branch from 63a6032 to 8c3602b Compare May 16, 2024 15:06

jolshan reviewed May 20, 2024

View reviewed changes

clients/src/main/java/org/apache/kafka/clients/producer/internals/Sender.java Outdated Show resolved Hide resolved

jolshan reviewed May 20, 2024

View reviewed changes

core/src/main/scala/kafka/server/KafkaApis.scala Outdated Show resolved Hide resolved

jolshan reviewed May 20, 2024

View reviewed changes

OmniaGM added 2 commits May 22, 2024 15:03

Merge branch 'trunk' into KAFKA-10551-produceRequest

cba0a2d

address part of the feedback

27ed97b

OmniaGM force-pushed the KAFKA-10551-produceRequest branch from 8daeb62 to 1abc2ac Compare May 28, 2024 15:43

Add testing for while recreate the topic and reassignment

35dba4b

OmniaGM force-pushed the KAFKA-10551-produceRequest branch from 1abc2ac to 35dba4b Compare May 28, 2024 16:02

Fetch supported produce version from apiVersions.

916e471

OmniaGM force-pushed the KAFKA-10551-produceRequest branch from 79814ff to 916e471 Compare June 11, 2024 21:22

Fetch supported produce version from apiVersions.

c59b10c

OmniaGM force-pushed the KAFKA-10551-produceRequest branch from 86c1f71 to c59b10c Compare June 11, 2024 21:25

Merge remote-tracking branch 'apache/trunk' into KAFKA-10551-produceR…

65d4a41

…equest

address feedback

5df61a4

junrao reviewed Apr 23, 2025

View reviewed changes

clients/src/test/java/org/apache/kafka/common/requests/ProduceRequestTest.java Show resolved Hide resolved

reduce usage of setName

eddd162

jolshan approved these changes Apr 24, 2025

View reviewed changes

junrao reviewed Apr 24, 2025

View reviewed changes

clients/src/test/java/org/apache/kafka/common/requests/ProduceRequestTest.java Outdated Show resolved Hide resolved

clients/src/test/java/org/apache/kafka/common/requests/ProduceRequestTest.java Show resolved Hide resolved

junrao reviewed Apr 28, 2025

View reviewed changes

clients/src/test/java/org/apache/kafka/common/requests/ProduceRequestTest.java Outdated Show resolved Hide resolved

OmniaGM added 2 commits April 29, 2025 09:54

address feedback

a2c2180

address feedback

4ee46d7

OmniaGM force-pushed the KAFKA-10551-produceRequest branch from 43e93b4 to 0c3e509 Compare April 29, 2025 09:01

Merge remote-tracking branch 'apache/trunk' into KAFKA-10551-produceR…

9abc966

…equest

OmniaGM force-pushed the KAFKA-10551-produceRequest branch from 0c3e509 to 9abc966 Compare April 29, 2025 14:34

junrao reviewed Apr 29, 2025

View reviewed changes

junrao approved these changes Apr 29, 2025

View reviewed changes

jolshan merged commit 6f783f8 into apache:trunk Apr 29, 2025
26 checks passed

junrao reviewed May 2, 2025

View reviewed changes

KAFKA-10551: Add topic id support to produce request and response #15968

KAFKA-10551: Add topic id support to produce request and response #15968

Uh oh!

Conversation

OmniaGM commented May 15, 2024 • edited by github-actions bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

OmniaGM commented May 16, 2024

Uh oh!

OmniaGM commented May 20, 2024

Uh oh!

jolshan commented May 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

OmniaGM May 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jolshan May 31, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

OmniaGM Jun 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jolshan commented May 20, 2024

Uh oh!

OmniaGM commented May 22, 2024

Uh oh!

junrao left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jolshan left a comment

Choose a reason for hiding this comment

Uh oh!

junrao left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

junrao left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

junrao left a comment

Choose a reason for hiding this comment

Uh oh!

jolshan commented Apr 29, 2025

Uh oh!

jolshan commented Apr 29, 2025

Uh oh!

junrao left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

OmniaGM commented Apr 30, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

OmniaGM commented May 15, 2024 •

edited by github-actions bot

Loading

jolshan commented May 20, 2024 •

edited

Loading

OmniaGM May 28, 2024 •

edited

Loading

jolshan May 31, 2024 •

edited

Loading

OmniaGM Jun 11, 2024 •

edited

Loading

OmniaGM commented Jun 13, 2025 •

edited

Loading