Repository navigation
Conversation
…(#22356) Previously, a static member rejoining a full modern consumer group could be rejected by the max group size check before the coordinator resolved that it was replacing an existing static member. Now, the max size check allows existing static members by `instanceId` to proceed to the static member validation/replacement path. New members are still rejected when the consumer group is at capacity, and unreleased static instance IDs still fail with the appropriate exception. Reviewers: nileshkumar3 <nileshkumar3@gmail.com>, David Jacot <david.jacot@gmail.com>
…on in group coordinator (#22264) The `deserialize*` methods in `ConsumerProtocol` only catch `BufferUnderflowException` and re-wrap it as `SchemaException`. Malformed bytes can also surface as other `RuntimeException`s (e.g. `IllegalArgumentException` from negative array lengths in `ByteBufferAccessor`), which escape these methods. Callers that only guard against `SchemaException` then propagate the failure, which can destabilize the group coordinator. ### Changes In `ConsumerProtocol`, broaden the `catch` clause from `BufferUnderflowException` to `RuntimeException` in all four deserialization entry points, re-wrapping as `SchemaException`: - `deserializeSubscription` - `deserializeConsumerProtocolSubscription` - `deserializeAssignment` - `deserializeConsumerProtocolAssignment` Reviewers: Sean Quah <squah@confluent.io>, David Jacot <david.jacot@gmail.com>
…t during online migration (#22580)
When the subscription deserialization fails, we throw an
IllegalStateException
```
private static ConsumerProtocolSubscription deserializeSubscription(
JoinGroupRequestProtocolCollection protocols
) {
try {
return ConsumerProtocol.deserializeConsumerProtocolSubscription(
ByteBuffer.wrap(protocols.iterator().next().metadata()));
}
catch (SchemaException e) {
throw new IllegalStateException("Malformed embedded consumer protocol
in subscription deserialization.");
}
}
```
which will be translated to UNKNOWN_SERVER_ERROR. This is a bit
confusing to the client. We throw a fatal `INCONSISTENT_GROUP_PROTOCOL`
here instead.
Reviewers: David Jacot <david.jacot@gmail.com>
…rd context (#22590) Fixes a regression introduced by KAFKA-19638: `TopologyTestDriver#getStateStore` now sets a dummy `ProcessorRecordContext` (`null` topic, `-1` offset/partition, timestamp `0`) unconditionally and never restores it. Before KAFKA-19638 the dummy context was set once at task construction and `getStateStore` was read-only. As a result, a store lookup mutates the task's live record context as a side effect. When a store handle is fetched while a record's context is active — an interactive query interleaved with processing, or a test seam that resolves a store handle through TTD from production code — the in-flight record's `RecordMetadata` is wiped: `recordMetadata().topic()` returns `null` and offset/partition become `-1`. Code building provenance from `recordMetadata().topic()` then fails, and direct store writes capture timestamp `0`. The normal `process()` path masks this because `doProcess` rebuilds the context per record, so it surfaces on direct store writes after a lookup and on any context read not preceded by a fresh `process()`. Fix: Only materialize the dummy context when none exists yet (before any record has been processed); never overwrite a live one. Direct store access still works, while an in-flight record's context is left intact. Reviewers: Matthias J. Sax <matthias@confluent.io>, Eduwer Camacaro <eduwerc@gmail.com>
…te retention (#22661) JIRA: https://issues.apache.org/jira/browse/KAFKA-20732 **Problem** On a freshly elected leader of a tiered partition, `RemoteLogManager` size-retention can run while `highestOffsetInRemoteStorage` is still `-1` — it is seeded only by the copy and follower tasks, which race the expiration task (both are scheduled with `initialDelay=0` on separate thread pools). `UnifiedLog.onlyLocalLogSegmentsSize()` then filters `baseOffset >= -1` and counts the entire local log, which is also counted in `remoteLogSizeBytes` for the same offsets. The apparent size roughly doubles, a false `retention.bytes` breach fires, and in-retention data is deleted from the remote tier and — via the resulting `logStartOffset` advance, replicated to followers — the local tier on all replicas. The follower path already guards this: `RLMFollowerTask.execute()` seeds the offset with the comment *"so that the local log segments are not deleted before they are copied to remote storage."* The leader/expiration path, which runs size-retention, had no equivalent step. **Fix** In `cleanupExpiredRemoteLogSegments`, when `highestOffsetInRemoteStorage() == -1`, seed it from remote metadata (`findHighestRemoteOffset`) before computing size-retention. It is a no-op once the offset is already seeded. **Testing** Added `RemoteLogManagerTest.testSizeRetentionDoesNotOverDeleteOnFreshLeaderUntilHighestRemoteOffsetSeeded` — fails without the fix (deletes both copied segments), passes with it. Also reproduced and fix-validated on a live 3.9.0 cluster (details in the JIRA). Reviewers: Luke Chen <showuon@gmail.com>, Kamal Chandraprakash <kamal.chandraprakash@gmail.com>
Upgrade log4j2 from 2.25.4 to 2.25.5. Reviewers: Mickael Maison <mickael.maison@gmail.com> Signed-off-by: Federico Valeri <fedevaleri@gmail.com>
This patch fixes a Jackson Databind vulnerability reported in: https: //nvd.nist.gov/vuln/detail/CVE-2026-54515 Reviewers: Mickael Maison <mickael.maison@gmail.com> --------- Signed-off-by: Federico Valeri <fedevaleri@gmail.com>
Backport of apache/kafka#22723 to 4.3. MetadataCache#toCluster builds a Cluster view for quota callbacks. Previously, it filtered fenced brokers out of the broker-to-node map, but partition metadata can still reference fenced brokers as replicas. When such replicas were converted to PartitionInfo, the missing broker entry could cause a NullPointerException. Include all registered brokers in the broker-to-node map so fenced replicas can be represented as offline replicas in the generated Cluster. Reviewers: Luke Chen <showuon@gmail.com>, Chia-Ping Tsai <chia7712@gmail.com>
…anager close on 4.3 (#22844) Port of the trunk PR #22837 and the original author is @nicktelford Reviewers: Matthias J. Sax <matthias@confluent.io>
…after TaskCorruptedException (#22855)
This PR ensures that an unsuccessfully opened segment is remove from the
in-memory cache for open segments.
Reviewers: Nick Telford <nick.telford@gmail.com>, Bill Bejeck
<bbejeck@apache.org><
8000
/pre>
…22915) KRaftControlRecordStateMachine reused a single BufferSupplier across all reads. The supplier returned by BufferSupplier.create() caches ByteBuffers by capacity without eviction, so the cached buffers lived as long as the state machine and consumed memory unboundedly. Create a fresh BufferSupplier per read in maybeLoadLog() and maybeLoadSnapshot() instead, allowing it to be released once the read completes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Reviewers: Kevin Wu <kwu@confluent.io>, Jonah Hooper <jhooper@confluent.io>, José Armando García Sancio <jsancio@apache.org>
…try when the input is truncated mid-entry (#22755) ListDeserializer.deserialize is using DataInputStream.read(byte[]) which may return "early" if the stream is shorter than expected (ie, cannot fill the provided `byte[]` array) w/o error. This can lead to a corrupted deserialization result. This PR switches to DataInputStream.readFully, which throws EOFException when the buffer cannot be filled. Reviewers: Matthias J. Sax <matthias@confluent.io>
…925) A task that fails to (re)initialize is left owned (registered and flagged failed) to be reconciled via the corruption/failed-task path. It is excluded from handleAssignment's rectify-existing pass (which iterates only non-failed tasks), so the next assignment builds a SECOND representation of it in createNewTasks; that duplicate fails init and trips the single-owner invariant in Tasks.addStandbyTask/addActiveTask (IllegalStateException: 'Attempted to create an standby task that we already own'), killing the StreamThread from an otherwise recoverable path. createNewTasks now skips creating any task the registry already owns (including failed ones), so the duplicate is never built and the single-owner invariant stays strict. Adds a TaskManagerTest regression test. Reviewers: Bill Bejeck <bbejeck@apache.org>
Fix the createTopics, createPartitions and alterPartitions code paths Reviewers: Paolo Patierno <ppatierno@live.com>, Gaurav Narula <gaurav_narula2@apple.com>, Luke Chen <showuon@gmail.com>
Bump jetty to 12.0.37 Reviewers: Luke Chen <showuon@gmail.com>, Ken Huang <s7133700@gmail.com>, Mickael Maison <mickael.maison@gmail.com> Signed-off-by: Federico Valeri <fedevaleri@gmail.com>
Bump lz4 to 1.11.1 Reviewers: Chia-Ping Tsai <chia7712@gmail.com>, Ken Huang <s7133700@gmail.com>
Backports the following fixes to the `4.3` branch: - #22073 - #22836 #22073 applied cleanly. #22836 conflicted only in the import section of `ShareHeartbeatRequestManagerTest`. The 4.3 branch already uses `anyBoolean()`, so the existing `anyBoolean` import was retained. The remaining changes and regression tests were applied unchanged. Testing: `./gradlew :clients:test --tests 'org.apache.kafka.clients.consumer.internals.AbstractCoordinatorTest' --tests 'org.apache.kafka.clients.consumer.internals.ConsumerHeartbeatRequestManagerTest' --tests 'org.apache.kafka.clients.consumer.internals.CoordinatorRequestManagerTest' --tests 'org.apache.kafka.clients.consumer.internals.ShareHeartbeatRequestManagerTest'` All four test classes pass locally on this branch. Reviewers: Mickael Maison <mickael.maison@gmail.com> --------- Co-authored-by: Evan Zhou <84255167+ezhou413@users.noreply.github.com>
…onse and time left (#22979) Fix to ensure that a new fetch request (new inflightPoll event) is sent right away in the case where a previous fetch event completed without records and there is still time to poll internally. Before this PR, a second iteration of the internal poll loop would not clear the previous event that was already done (and generated no data), so it would block on the buffer before sending a next fetch, introducing latency. Fix by ensuring that the inflight poll is cleared if completed before checking the need to send a new one. Reviewers: Andrew Schofield <aschofield@confluent.io>
In "classic" group protocol, IQ metadata is handled per client, while it's handled per group member (aka StreamsThreads) in the new "streams" protocol. However, StreamsGroupHeartbeatRequestManager only maintains a single metadata copy, and thus different member's metadata overwrites each other. This PR ensures that IQ metadata from different members of the same client is preserved correctly by merging it, instead of overwriting. Reviewers: Alieh Saeedi <asaeedi@confluent.io>, Matthias J. Sax <matthias@confluent.io>
The cherry-pick of apache/kafka#22778 into 4.3 was not clean, and the commit does not contain all changes. This PR fixed the broken branch.
…(#23050) EndpointToPartitionsManager clamped the partitions it reports for a member by comparing the topic's partition count against the *number* of tasks the member owns, and then keeping the lowest task IDs. That is only correct when a single member owns the whole subtopology. A subtopology has as many tasks as its source topic with the most partitions, so a smaller source topic has no partition for the higher task IDs. When a member owns a "non-prefix" task set, the size-based check does not fire and the task IDs are reported verbatim as partitions of that smaller topic, advertising partitions that do not exist. Filter the task IDs by value, and omit a source topic entirely when none of the member's tasks map to one of its partitions. This mirrors PartitionGrouper#partitionGroups, which computes the same mapping for the classic protocol. Reviewers: Bill Bejeck <bbejeck@apache.org>
…assignor (#23082) (#23089) The `StateDirectory` offset cache should only contain data for persistent state store. This PR avoids the offset from in-memory state stores are added to the cache, and ensure that the read path fills in missing information for other state stores (in particular in-memory ones) on the fly. Reviewers: Nick Telford <nick.telford@gmail.com>, Bill Bejeck <bbejeck@apache.org>
…tively (#22999) This PR ensures that KafkaStreams fails with a clear error message if a bad task assignment is received from the broker. Reviewers: Zheguang Zhao <zheguang.zhao@gmail.com>, Lianet Magrans <lmagrans@confluent.io>
…ies but not processing delays (#22452) The record-e2e-latency metric at terminal nodes is computed incorrectly, using a cached timestamp which is take before actual processing happens. This PR ensures, that we are taking a new timestamp after processing completed. To avoid per-record system calls, we take a single timestamp after a batch of records completed. During processing, we capture record.timestamp values (eg, min, max, etc) allowing us to compute the latency per record at the end of a batch. Reviewers: Lucy Liu <lucliu@confluent.io>, Matthias J. Sax <matthias@confluent.io>
Broker side StickyTaskAssignor does not assign standby tasks correctly, because it does not cycle through all group member correctly to find the right candidate to host it. Reviewers: Mingi Cho (github:ChoMinGi), Bill Bejeck <bbejeck@apache.org>
If the broker side assignor makes an error on task assignment, it could crash the client with a "duplicate taskId" error. This PR adds a proper task-id deduplication guard plus new WARN logs to let the user know that it received some bad assignment. Reviewers: Bill Bejeck <bbejeck@apache.org>
The `restore-remaining-records-total` task metric overshoots and never reaches zero. The code does initialize the metric based on offset difference (`endOffset - startOffset`), but counts down based on number of records restored, not taking "missing offsets" from log compaction, TX markers, or aborted messages (under EOS) into account. This fix makes the decrements consistent with the initialization by expressing the remaining-records metric's progress in changelog offset slots rather than record counts. Reviewers: Matthias J. Sax <matthias@confluent.io>
…093) - Added logic to catch and propagate to the stream thread fatal state update errors. - Improved the error handling logic in the state updater thread. Now when the thread is failing it marks all tasks as failed. - Added logic to fail task removal futures if the thread is dead. Reviewers: Matthias J. Sax <matthias@confluent.io>
Both metrics incorrectly report "batches restored per second" instead of "records restored per seconds". Reviewers: Alieh Saeedi <asaeedi@confluent.io>, Bill Bejeck <bbejeck@apache.org>
…re a StoreBuilder (#22102) [KAFKA-20464](https://issues.apache.org/jira/browse/KAFKA-20464) `ConnectedStoreProvider` Javadoc documents that multiple providers may return the same `StoreBuilder` instance to share a store. Currently this places the processors in separate subtopologies because `addStateStore()` overwrites the `stateFactories` entry, losing the previous `connectedProcessorNames`. The fix is a one-line conditional: skip the put when a compatible factory already exists. Tests added in `StreamsBuilderTest` and `InternalTopologyBuilderTest`. On upgrade, affected topologies will see subtopology regrouping — task IDs from the previously separate subtopology will no longer exist, and their state will be restored from changelog topics on first restart. Reviewers: @UladzislauBlok , Bill Bejeck <bbejeck@apache.org>
Adds the KAFKA-20464 upgrade-guide note from #22102 to the 4.3 branch. The code fix was already cherry-picked to 4.3 in [b46933f](apache/kafka@b46933f). Reviewers: Bill Bejeck <bbejeck@apache.org>
Addressing comments from apache/kafka#23258 Reviewers: Chia-Ping Tsai <chia7712@gmail.com>, Jun Rao <junrao@gmail.com>
…k (#23464) SharePartition registers Yammer gauges (InFlightMessageCount, InFlightBatchCount, etc.) whose suppliers capture the SharePartition instance. These gauges were never deregistered when a partition was removed from the cache, so the metrics registry kept a strong reference to every fenced SharePartition (and its cachedState) for the lifetime of the broker. Make SharePartition implement AutoCloseable and deregister its metrics in close() via SharePartitionMetrics Verified against a live heap dump: after the fix there are zero live SharePartition and AcquisitionLockTimerTask instances; the only remaining SharePartition$$Lambda is a non-capturing per-call-site singleton (zero captured fields) bound to the class, not to any instance. Reviewers: Andrew Schofield <aschofield@confluent.io>, Abhinav Dixit <adixit@confluent.io>
Sync the "Upgrading to 4.3.1" section from kafka-site (apache/kafka-site#889) to `docs/getting-started/upgrade.md`, and bump the versions in `docs/apis/_index.md` to 4.3.1. This is the 4.3 branch version of #23462. Without this, the section would be overwritten by the docs generated from this branch in the next 4.3.x release. Reviewers: Ken Huang <s7133700@gmail.com>, Chia-Ping Tsai <chia7712@gmail.com>
Generated request/response readers sized array and tagged-field collections directly from the sender-declared count. The existing check bounds a declared count against the remaining buffer bytes, but that bound assumes roughly one byte per element; a count that passes it can still translate into a large initial allocation once elements are unpacked into Java objects, and tagged-field counts had no remaining-bytes check at all. Adds, mirroring the existing array-length guard: - Initial pre-allocation for array/collection fields is capped at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000); a larger declared count still parses correctly, growing the collection on demand as elements are read. - A declared array/collection length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000) is now rejected up front. - The tagged-field count for flexible-versioned messages is now checked the same way array lengths already are: rejected if negative, if it exceeds the remaining bytes, or if it exceeds MessageUtil.MAX_TAGGED_FIELD_COUNT (10,000). New tests cover the pre-allocation cap and hard-length cap on both the ArrayList and keyed-collection (ImplicitLinkedHashMultiCollection) branches, at the generator level and in a runtime round-trip, the new tagged-field guards, and end-to-end RequestContext/RequestHeader cases using the actual ProduceRequestData (v3) and RequestHeaderData (v2) production classes at large declared-count magnitudes backed by real padding bytes, so the pre-existing remaining-bytes check alone would not reject them and the new hard caps are what's being exercised. Co-authored-by: Izzy Harker <100494820+izzyharker@users.noreply.github.com> Co-authored-by: Alyssa Huang <ahuang@confluent.io> Co-authored-by: Truc Nguyen <119303279+trnguyencflt@users.noreply.github.com> Co-authored-by: Shay Elkin <2046772+shayelkin@users.noreply.github.com>
…3510) ShareSessionCache `.remove` and `.maybeCreateSession` are each individually synchronized — but as two separate calls, not one atomic unit. If two connections sent an INITIAL_EPOCH request for the same (groupId, memberId), *faulty client*, at nearly the same time then both proceed to create a session. `maybeCreateSession` increments numMembersPerGroup and numPartitions every time it's called. The sessions map only ever holds one entry per key (second write overwrites the first), but the counters had already been bumped twice. on disconnect, only the connection whose mapping still pointed at a live session gets to decrement the counters. So numMembersPerGroup for that group gets stuck above zero forever, which means onGroupEmpty never fires. Reviewers: Andrew Schofield <aschofield@confluent.io>, Manikumar Reddy <manikumar.reddy@gmail.com>
The yammerMetricValue implementation in trunk is changed and moved to another class where it propagates the exception while current implementation swallows. Hence moved the check to keep the changes minimal and least different from trunk. The SharePartitionManager fix is due to different Mockito versions and default return behaviour from trunk to current branch. Reviewers: TengYao Chi <frankvicky@apache.org>
A corrupted EOS task is wiped and revived as the same `StreamTask` object, but `consumedOffsets` survived the close. For a `KTable` that uses its source topic as its changelog, the next checkpoint stamped those pre-corruption offsets onto the empty store. The store then looked fully restored, and the task ran with its `KTable` missing data. Clearing consumedOffsets in close() makes the wiped store restore from its actual position. The integration test in this PR fails without this fix. SourceTopicChangelogRestoreIntegrationTest was not included because it depends on KafkaProtocolFaultProxy, which is not on 4.3. Reviewers: Lucas Brutschy <lbrutschy@confluent.io>
Use the same array length limits as the generated message readers. Co-authored-by: Anastasia Vela <avela@confluent.io> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ead (#23004) JIRA: KAFKA-20873 `KafkaStreams.removeStreamThread(long)` used to hold the `changeThreadCount` monitor while waiting for the removed thread to reach DEAD. When the removal target was the same StreamThread that concurrently entered the REPLACE_THREAD uncaught-exception handler, its `replaceStreamThread -> addStreamThread` path blocked on the same lock, so the target never reached DEAD and the waiter waited forever. `removeStreamThread` now signals the shutdown under the lock, waits for DEAD without holding it, and re-acquires it for the bookkeeping. Releasing the lock exposes races between removal, thread replacement, and close, resolved by a single rule: whoever wins the atomic transition to PENDING_SHUTDOWN owns the thread's death and decides its group membership operation. A losing REPLACE_THREAD handler does not spawn a replacement, so a removal is not silently undone; a losing removal skips the thread and scans on, returning `Optional.empty()` when nothing was removed; a later shutdown request (including close) never changes the operation the owner chose, and the failure-path LEAVE_GROUP default equally yields to an already-initiated shutdown. The bookkeeping also keeps the store-provider registration of a live thread that reused the removed thread's name, and only throws a TimeoutException when the wait for DEAD actually timed out. Unit tests cover the concurrent-removal, lost-shutdown, name-reuse, and operation-ownership interleavings; an integration test fails a thread with REPLACE_THREAD after a removal wins its shutdown and asserts no replacement is spawned. Reviewers: Matthias J. Sax <matthias@confluent.io>, Lucas Brutschy <lbrutschy@confluent.io> (cherry picked from commit 051a1860d55ee96eec2eb2c75ee1d6dd7c5183c9)
Add 4.3.2 notable changes. Reviewers: PoAn Yang <payang@apache.org>, Chia-Ping Tsai <chia7712@gmail.com>
4.3.2-rc0
Fix documentation for CVE-2026-41115, to use `DESCRIBE` permission on `GROUP` resource for `CONSUMER_GROUP_DESCRIBE (69)` API. Reviewers: David Jacot <david.jacot@gmail.com>
…e (#23627) Reject non-finite client quota values in `ClientQuotaControlManager`, and cap the byte-rate throttle time to `Integer.MAX_VALUE` before narrowing it to int in `ClientQuotaManager`. Reviewers: Hritwik Singhai (github:devhritwik), Manikumar Reddy <manikumar.reddy@gmail.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Add same CreateTopics validation to CreatePartitions Reviewers: Manikumar Reddy <manikumar@confluent.io> Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
… tasks (4.3) (#23677) When a `CoordinatorExecutorImpl` task is cancelled, it remains in the executor queue or in the event processor queue until it is processed and it retains its runnable, its operation and the result of its runnable in the meantime. When the group coordinator is overloaded, these queues can grow large and retain data structures that are no longer needed, e.g. the metadata image captured by the regular expression resolution. This patch boxes the runnable, the operation and the result in a `Task` object which releases them when the task is cancelled. The operation and the result are also released once the operation is executed because the write event is retained until its records are committed. Reviewers: Sean Quah <squah@confluent.io>
This reverts commit a219569.
Backport of the snappy-java bump from KAFKA-21126 (#23426). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bump Jackson version to 2.22.3 for 4.3 Fix CVE: - [CVE-2026-89407 — OpenCVE](https://app.opencve.io/cve/CVE-2026-89407) - [CVE-2026-89425 — OpenCVE](https://app.opencve.io/cve/CVE-2026-89425) - [CVE-2026-91776 — Strix](https://www.strix.ai/cve/CVE-2026-91776) - [CVE-2026-91777 — Strix](https://www.strix.ai/cve/CVE-2026-91777) Reviewers: Chia-Ping Tsai <chia7712@gmail.com>
#23748 bumped Jackson on 4.3 from 2.21.x to 2.22.3 to pick up the CVE fixes. That moves a patch release line to a new minor line of Jackson, which we normally avoid. 2.21.7 contains the same fixes, so this change goes back to the 2.21.x line: - CVE-2026-89407 (jackson-core) - CVE-2026-89425 (jackson-core) - CVE-2026-91776 (jackson-databind) - CVE-2026-91777 (jackson-databind) See #23748 (comment) for the discussion. Reviewers: Chia-Ping Tsai <chia7712@gmail.com>, Ken Huang <s7133700@gmail.com>
This reverts commit 30e0c71.
Fix lz4 CVE for 4.3 - [CVE-2026-106451 — OpenCVE](https://app.opencve.io/cve/CVE-2026-106451) - [CVE-2026-106451 — GitLab Advisory](https://advisories.gitlab.com/maven/at.yawk.lz4/lz4-java/CVE-2026-106451/) - [CVE-2026-106451 — cvereports](https://cvereports.com/reports/CVE-2026-106451) Reviewers: PoAn Yang <payang@apache.org>
# Conflicts: # committer-tools/kafk ACA0 a-merge-pr.py # core/src/main/scala/kafka/server/KafkaApis.scala # gradle.properties # server/src/test/java/org/apache/kafka/server/config/DynamicBrokerConfigTest.java # storage/src/main/java/org/apache/kafka/server/log/remote/storage/RemoteLogManager.java # storage/src/test/java/org/apache/kafka/server/log/remote/storage/RemoteLogManagerTest.java # streams/quickstart/java/pom.xml # streams/quickstart/java/src/main/resources/archetype-resources/pom.xml # streams/quickstart/pom.xml # tests/kafkatest/__init__.py # tests/kafkatest/version.py Assisted-by: Claude Opus 5.5
The session log records the 11 conflicts from merging Apache Kafka 4.3.2 into `inkless-4.3`, how each one was resolved, and the checks run before the PR. Assisted-by: Claude Opus 5.5
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
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.
Merges Apache Kafka
4.3.2intoinkless-4.3: 102 upstream commits on top of the4.3.1base, which already carries Inkless 0.51. The patch release brings upstream fixes and dependency bumps (Jackson, Jetty, JLine, Log4j 2, LZ4, and snappy-java), and the version moves to4.3.2-inkless.Conflict resolution
The merge had 11 conflicts. Seven are the version files that
inkless-sync/RELEASE-SYNC-GUIDE.mdcovers. Each keeps the Inkless suffix with the new version:gradle.properties,committer-tools/kafka-merge-pr.py, andtests/kafkatest/version.pyuse4.3.2-inkless.tests/kafkatest/__init__.pyuses4.3.2+inkless.streams/quickstartPOM files use4.3.2-inkless.The other four keep both sides:
core/src/main/scala/kafka/server/KafkaApis.scala: upstream skips the share fetch bytes-out metric when the topic name is unknown. The merge keeps that check and still passes the InklessisDisklessflag toupdateBytesOut, computed from the same topic name.storage/src/main/java/org/apache/kafka/server/log/remote/storage/RemoteLogManager.java: upstream callsmaybeSeedHighestOffsetInRemoteStorage(log)before size-based retention. The merge keeps that call, followed by the InklessreclaimFloorLogStartOffset(log)lookup.RemoteLogManagerTest.javaandserverDynamicBrokerConfigTest.java: both sides added an import or a test at the same spot, and the merge keeps both.gradle/dependencies.gradlemerged without conflicts, and each key appears once. No conflict touched an Inkless-owned path.The session log is at
inkless-sync/sessions/RELEASE-SESSION-inkless-4.3-2026-11-06.md.Testing
./gradlew compileTestJava compileTestScalapasses../gradlew verifyVersionConsistencyreports that all versions match.:storage:inkless:test, plus the server, storage, metadata, and core suites around the conflicts and the switch and consolidation paths. CI runs the full suite.After merge
Tag the new branch head as
inkless-4.3.2-0.51. Pushing the tag builds the4.3.2-0.51Docker images and moves the4.3-latestalias. Theinkless-release-0.51GitHub Release doesn't change.🤖 Generated with Claude Code