KAFKA-15599: Move KafkaMetadataLog to the raft module #19762

mimaison · 2025-05-19T18:42:51Z

Rename KafkaMetadataLog to KafkaRaftLog
Make raft depend on storage
Remove storage dependency on metadata as this otherwise create a
cyclic dependency

dengziming · 2025-05-21T02:35:57Z

There are some concerns regarding this change, though we haven't made kraft a public API, we are trying to keep it dependency-free to be used as a raft-sdk anywhere. For example, if you are implementing a system with metadata changing frequently, you can directly copy kraft code into your project.
This assumption also has some benefits to the whole Kafka architecture, this change reduced dependency complexity but breaked this assumption, we should evaluate which goal is more important.

mimaison · 2025-05-21T16:33:43Z

we are trying to keep it dependency-free to be used as a raft-sdk anywhere

Where has this been discussed?
The way Kafka implements Raft is via a topic so our implementation of ReplicatedLog needs to depend on storage. Since metadata depends on raft, the other option is to put KafkaMetadataLog into the metadata module and have that depend on storage instead of raft.

dengziming · 2025-05-22T06:44:59Z

Where has this been discussed?

In KIP-595 we wrote:

We are also trying to pave the way for normal partition replication through Raft as well as eventually supporting metadata sharding with multiple partitions.

We are only trying to pave the way for Kafka normal partition replication instead of making it SDK exportable, I may have thought too much about it, but the idea behind it still deserves consideration, for example, etcd-raft(https://github.com/etcd-io/raft) also follows a similar principle to not include a concrete log implementation.
Moving it to metadata module is better compared putting it in raft module, and we should not rename it to KafkaRaftLog since we can use raft to replicate normal partition.

mimaison · 2025-05-22T09:49:48Z

I'm not sure I interpret that statement from KIP-595 as an intent to keep the raft module dependency free. As you said the raft module is not public API, and I've not seen any discussions in that direction.

The metadata module mostly consists of the data structures written to the metadata log. To me it seems the logic of maintaining the metadata log as a topic fits better in the raft module, as described in https://issues.apache.org/jira/browse/KAFKA-15599.

dengziming · 2025-05-23T06:19:56Z

@mimaison That makes sense to me, 👍 if we should make the tradeoff, the modularity outweighs the pluggability of the raft module, @jsancio @ijuma, where do you think is better to put KafkaMetadataLog.

ijuma · 2025-05-23T16:22:09Z

The description I wrote in the ticket was the conclusion after a discussion with a few people including @jsancio and @cmccabe. @jsancio does that approach still make sense to you?

ijuma · 2025-05-23T16:23:57Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+import java.util.concurrent.atomic.AtomicLong;
+import java.util.function.Function;
+
+public class KafkaRaftLog implements ReplicatedLog {


The JIRA ticket also talked about renaming ReplicatedLog to RaftLog. Do we want to do that separately or we think it's not a good idea? cc @jsancio

I think RaftLog is a nicer name. I can do it in this PR.

dengziming

Thank you for this PR, I left some comments, PTAL.

dengziming · 2025-05-29T12:41:05Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+                    deleted = deletedSegments != 0 || !forgottenSnapshots.isEmpty();
+                }
+            }
+            removeSnapshots(forgottenSnapshots, reason);


Why did we move this inside of synchronized block?

You're right this can be moved outside of the synchronized block

dengziming · 2025-05-29T12:43:21Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+                    )
+            );
+        } catch (IOException ioe) {
+            throw new UncheckedIOException(ioe);


Maybe it's a newcomer's question, is UncheckedIOException better than IOException?

UncheckedIOException is unchecked while IOException is checked. However, it's risky to make this change as you have to check that every caller handles the new exception and the compiler will not help you - the way we did it for other classes was not to change exception types during conversion from Scala to Java. And to have a separate JIRA for investigating this.

The reason I used UncheckedIOException is that none of the method definitions in RaftLog are marked as throwing exceptions. None of the calling logic, mostly in KafkaRaftClient, has logic to handle checked exceptions.

So any exception throw will be passed back up the call stack to KafkaRadftClientDriver.doWork() that has catches Throwable.

Perhaps it's better to wrap this in KafkaException to distinguish it from other UncheckedIOException? Ditto in a few other places.

dengziming · 2025-05-29T12:44:48Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+    @Override
+    public Optional<OffsetAndEpoch> earliestSnapshotId() {
+        synchronized (snapshots) {
+            try {


Updated to match latestSnapshotId()

dengziming · 2025-05-29T12:45:10Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+            try {
+                OffsetAndEpoch epoch = snapshots.lastKey();
+                return epoch == null ? Optional.empty() : Optional.of(epoch);
+            } catch (NoSuchElementException e) {


How about changing this NoSuchElementException catching code to if snapshots.isEmpty()

dengziming · 2025-05-29T12:48:46Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+        for (OffsetAndEpoch key : snapshots.keySet()) {
+            Optional<RawSnapshotReader> snapshotReader = readSnapshot(key);
+            snapshotReader.ifPresent(fileRawSnapshotReader -> {
+                    snapshots.put(key, Optional.of((FileRawSnapshotReader) snapshotReader.get()));


Why should we put it here?

Good catch, it shouldn't be there. The call to readSnapshot() will have opened the reader and updated snapshots already.

brandboat · 2025-05-29T16:07:19Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+            int nodeId) throws IOException {
+        Properties props = new Properties();
+        props.setProperty(TopicConfig.MAX_MESSAGE_BYTES_CONFIG, String.valueOf(config.maxBatchSizeInBytes()));
+        props.setProperty(TopicConfig.SEGMENT_BYTES_CONFIG, String.valueOf(config.logSegmentBytes()));


Just a reminder — we recently introduced some changes in KafkaMetadataLog (see bcda92b#diff-b332f85b04775c821226b6f704e91d51f9647f29ba73dace65b99cf36f6b9cea)

Thanks for the heads-up!

dengziming

All lgtm.

junrao

@mimaison : Thanks for the PR. Left a few comments.

junrao · 2025-06-30T23:13:26Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+        this.snapshots = snapshots;
+        this.topicPartition = topicPartition;
+        this.config = config;
+        this.logIdent = "[MetadataLog partition=" + topicPartition + ", nodeId=" + nodeId + "] ";


Should we change MetadataLog to RaftLog?

junrao · 2025-06-30T23:22:43Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+        } else {
+            props.setProperty(TopicConfig.SEGMENT_BYTES_CONFIG, String.valueOf(config.logSegmentBytes()));
+        }
+        props.setProperty(TopicConfig.FILE_DELETE_DELAY_MS_CONFIG, String.valueOf(ServerLogConfigs.LOG_DELETE_DELAY_MS_DEFAULT));


It seems that we are missing the following.

props.setProperty(TopicConfig.SEGMENT_MS_CONFIG, config.logSegmentMillis.toString)

junrao · 2025-06-30T23:28:14Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+                nodeId
+        );
+
+        // When recovering, truncate fully if the latest snapshot is after the log end offset. This can happen to a follower


Why was the following validation removed?

if (defaultLogConfig.segmentSize() < config.logSegmentBytes()) { metadataLog.error(s"Overriding ${MetadataLogConfig.INTERNAL_METADATA_LOG_SEGMENT_BYTES_CONFIG} is only supported for testing. Setting " + s"this value too low may lead to an inability to write batches of metadata records.") }

junrao · 2025-06-30T23:40:54Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+
+            for (SnapshotPath snapshotPath : snapshotsToDelete) {
+                Files.deleteIfExists(snapshotPath.path());
+                LOG.info("Deleted unneeded snapshot file with path {}", snapshotPath);


Should we add the partition level indent ?

junrao · 2025-06-30T23:45:05Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+        String reason(OffsetAndEpoch snapshotId);
+    }
+
+    static class RetentionMsBreach implements SnapshotDeletionReason {


Should we change it to record? Ditto for RetentionSizeBreach.

I changed all the SnapshotDeletionReason implementations to record

junrao · 2025-07-01T23:20:53Z

raft/src/test/java/org/apache/kafka/raft/KafkaRaftLogTest.java

+    @Test
+    public void testConfig() throws IOException {
+        Properties props = new Properties();
+        props.put("process.roles", "broker");


Should we move KRaftConfigs to the raft module so that we could use the defined config names?

junrao · 2025-07-01T23:29:57Z

raft/src/test/java/org/apache/kafka/raft/KafkaRaftLogTest.java

+        mockTime.sleep(config.internalDeleteDelayMillis());
+        // Assert that the log dir doesn't contain any older snapshots
+        Files
+                .walk(logDir, 1)


Could this be merged with the previous line?

junrao · 2025-07-01T23:39:14Z

raft/src/test/java/org/apache/kafka/raft/KafkaRaftLogTest.java

+        OffsetAndEpoch snapshotId1 = new OffsetAndEpoch(1000, 1);
+        RawSnapshotWriter snapshot = log.createNewSnapshotUnchecked(snapshotId1).get();
+        append(snapshot, 500);
+        snapshot.freeze();


Should we close snapshot as before? Ditto below.

junrao · 2025-07-01T23:40:35Z

raft/src/test/java/org/apache/kafka/raft/KafkaRaftLogTest.java

+    }
+
+    @Test
+    public void testSegmentsLessThanLatestSnapshot() throws IOException {


Why did we skip testSegmentMsConfigIsSetInMetadataLog() in the old test ?

This test was added after I opened the PR. I must have missed it while rebasing.

junrao · 2025-07-01T23:48:10Z

metadata/src/main/java/org/apache/kafka/image/TopicsImage.java

+     * @param log            The log
+     * @return true if the topic partition should not exist on the broker, false otherwise.
+     */
+    public static boolean isStrayReplica(TopicsImage newTopicsImage, int brokerId, Optional<Uuid> topicId, int partitionId, String log) {


Should this be put in metadata.util?

The reasons I put it here are that:

it's a single method related to TopicsImage

the TopicsImageTest class has utility methods that helped simplify the test logic

Why make this static if the first argument is TopicsImage? This looks a lot like an object method where the this reference is the TopicsImage.

It was static mostly for historical reasons as I just copied it from LogManager but you're right since the first argument is a TopicsImage the new method I added is now not static.

junrao

@mimaison : Thanks for the updated PR. A few more comments. Also, there are compilation errors.

junrao · 2025-07-02T23:33:31Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+                    FileRawSnapshotReader fileReader = FileRawSnapshotReader.open(log.dir().toPath(), snapshotId);
+                    snapshots.put(snapshotId, Optional.of(fileReader));
+                    return Optional.of(fileReader);
+                } catch (UncheckedIOException e) {


The following path is only for NoSuchFileException. For other IOExceptions, we should propagate to the caller.

Which method do you see throwing NoSuchFileException?

According to https://stackoverflow.com/questions/63638250/nio-channels-filechannel-open-threw-nosuchfileexception, FileChannel.open() could throw NoSuchFileException.

Ah right, going down the whole call stack, I see that UnixFileSystemProvider uses UnixException.translateToIOException() and that maps ENOENT to NoSuchFileException.

I wonder if the existing code is broken as FileRawSnapshotReader.open() wrap the IOException into UncheckedIOException so the current catch block should be not entered.

I made the change and added a test case checking NoSuchFileException. However I can't find a way to reliably force another type of IOException to check these are thrown.

junrao · 2025-07-02T23:37:14Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

+                    )
+            );
+        } catch (IOException ioe) {
+            throw new KafkaException(ioe);


I noticed that existing code like Snapshots and FileSnapshotReader convert IOException to UncheckedIOException. It's probably better to follow that convention for now.

Yes the whole raft module pretty much only uses UncheckedIOException.

junrao · 2025-07-02T23:50:28Z

metadata/src/test/java/org/apache/kafka/image/TopicsImageTest.java

+    public void testIsStrayReplicaWithEmptyImage() {
+        TopicsImage image = topicsImage(List.of());
+        List<TopicIdPartition> onDisk = List.of(FOO_0, FOO_1, BAR_0, BAR_1, BAZ_0);
+        assertTrue(onDisk.stream().allMatch(log ->


It seems that this hasn't been addressed?

junrao · 2025-07-02T23:53:22Z

raft/src/test/java/org/apache/kafka/raft/KafkaRaftLogTest.java

+        mockTime.sleep(config.internalDeleteDelayMillis());
+        // Assert that the log dir doesn't contain any older snapshots
+        Files.walk(logDir, 1)
+                .map(Snapshots::parse)


This indentation is different from the one in line 628.

junrao · 2025-07-02T23:56:46Z

raft/src/test/java/org/apache/kafka/raft/KafkaRaftLogTest.java

+        // Simulate log cleanup that advances the LSO
+        log.log().maybeIncrementLogStartOffset(snapshotId.offset() - 1, LogStartOffsetIncrementReason.SegmentDeletion);
+
+        assertEquals(Optional.empty(), log.createNewSnapshot(new OffsetAndEpoch(snapshotId.offset() - 2, snapshotId.epoch())));


Should we close the created snapshot?

We expect createNewSnapshot() to return Optional.empty(), so there should be nothing to close.

junrao · 2025-07-02T23:57:32Z

raft/src/test/java/org/apache/kafka/raft/KafkaRaftLogTest.java

+        log.updateHighWatermark(new LogOffsetMetadata(numberOfRecords));
+        createNewSnapshot(log, snapshotId);
+
+        assertEquals(Optional.empty(), log.createNewSnapshot(snapshotId),


Should we close the created snapshot?

We expect createNewSnapshot() to return Optional.empty(), so there should be nothing to close.

junrao

@mimaison : Thanks for the updated PR. Just a comment based on Jose's feedback. Also, could you resolve the conflicts?

jsancio

Thanks for the changes I still need to review the new KafkaRaftLog files but here are some early comments.

jsancio · 2025-07-07T16:32:23Z

raft/src/main/java/org/apache/kafka/raft/KafkaRaftLog.java

I am thinking that we should make this internal by moving the implementation to o.a.k.r.internals.KafkaRaftLog.java. The same of the accompanying test suite file.

jsancio · 2025-07-07T16:37:29Z

checkstyle/import-control.xml

    <allow class="org.apache.kafka.common.compress.Compression" exact-match="true" />
    <allow pkg="org.apache.kafka.common.config" />
    <allow pkg="org.apache.kafka.common.feature" />
+    <allow pkg="org.apache.kafka.common.internals" />


Note that to me this means that the common module is not organized correctly if the raft module needs types in the "internals" namespace. Same comment applies to the change below which also includes o.a.k.s.internals.log.

internals simply means it should not be used outside the kafka repo. This is more explicit than the uncommon "check the javadoc" to check if the class is public or internal.

jsancio · 2025-07-07T16:48:30Z

metadata/src/main/java/org/apache/kafka/image/TopicsImage.java

+     * @param log            The log
+     * @return true if the topic partition should not exist on the broker, false otherwise.
+     */
+    public static boolean isStrayReplica(TopicsImage newTopicsImage, int brokerId, Optional<Uuid> topicId, int partitionId, String log) {


Why make this static if the first argument is TopicsImage? This looks a lot like an object method where the this reference is the TopicsImage.

jsancio · 2025-07-07T16:49:17Z

metadata/src/main/java/org/apache/kafka/image/TopicsImage.java

+        if (topicId.isEmpty()) {
+            // Missing topic ID could result from storage failure or unclean shutdown after topic creation but before flushing
+            // data to the `partition.metadata` file. And before appending data to the log, the `partition.metadata` is always
+            // flushed to disk. So if the topic ID is missing, it mostly means no data was appended, and we can treat this as
+            // a stray log.
+            LOG.info("The topicId does not exist in {}, treat it as a stray log.", log);
+            return true;
+        }


How about letting the log manager make this decision? In Kafka 4.0 all topics must have a topic id.

jsancio · 2025-07-07T16:51:48Z

metadata/src/main/java/org/apache/kafka/image/TopicsImage.java

+        PartitionRegistration partition = newTopicsImage.getPartition(topicId.get(), partitionId);
+        if (partition == null) {
+            LOG.info("Found stray log dir {}: the topicId {} does not exist in the metadata image.", log, topicId);
+            return true;
+        } else {
+            List<Integer> replicas = Arrays.stream(partition.replicas).boxed().toList();
+            if (!replicas.contains(brokerId)) {
+                LOG.info("Found stray log dir {}: the current replica assignment {} does not contain the local brokerId {}.",
+                        log, replicas.stream().map(String::valueOf).collect(Collectors.joining(", ", "[", "]")), brokerId);
+                return true;
+            } else {
+                return false;
+            }
+        }
+    }


To me this should be a functionality of the log manager. Maybe the TopicsImage method should just return all of the topic ids that don't exist in the given image and broker.

This would allow you to remove that added static logger.

jsancio · 2025-07-07T16:56:49Z

core/src/main/scala/kafka/server/metadata/BrokerMetadataPublisher.scala

      logManager.startup(
        metadataCache.getAllTopics().asScala,
-        isStray = log => JLogManager.isStrayKraftReplica(brokerId, newImage.topics(), log)
+        isStray = log => TopicsImage.isStrayReplica(newImage.topics(), brokerId, log.topicId(), log.topicPartition().partition(), log.toString)


Minor but to me stray partition are in the log manager not in the topics image. Meaning the log manager has partition entries that are not in the latest topics image.

In some sense the log manager understand topics image and makes sure that they match. The topics images doesn't know anything about "stray partitions" and the log manager.

If you still want to move the functionality TopicsImage maybe make it a method (not static) with Stream<TopicIdPartition> deletedPartitionsForReplica(int brokerId, Stream<TopicIdPartition>).

I introduced a more generic method in TopicsImage called partitionReplicas(), and moved the logic specific to stray partitions back to LogManager.

mimaison · 2025-08-06T16:04:27Z

@jsancio Can you take another look? Thanks

junrao

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

junrao · 2025-08-12T23:19:17Z

raft/src/main/java/org/apache/kafka/raft/internals/KafkaRaftLog.java

+            if (reader == null) {
+                return Optional.empty();
+            } else if (reader.isPresent()) {
+                return Optional.of(reader.get());


We can just return reader here?

I'm rewrapping it here as the generic type does not match. reader is a Optional<FileRawSnapshotReader> while we need to return Optional<RawSnapshotReader>

junrao · 2025-08-13T00:08:37Z

core/src/main/scala/kafka/server/metadata/BrokerMetadataPublisher.scala

        metadataCache.getAllTopics().asScala,
-        isStray = log => JLogManager.isStrayKraftReplica(brokerId, newImage.topics(), log)
+        isStray = log => {
+          if (log.topicId().isEmpty) {


Could we keep this part in JLogManager.isStrayReplica()?

The reason I kept this here is because I wanted to keep the else block here since it's using newImage which we're trying not to use in JLogManager

junrao · 2025-08-13T00:11:56Z

storage/src/main/java/org/apache/kafka/storage/internals/log/LogManager.java

-            // flushed to disk. So if the topic ID is missing, it mostly means no data was appended, and we can treat this as
-            // a stray log.
-            LOG.info("The topicId does not exist in {}, treat it as a stray log.", log);
+    public static boolean isStrayReplica(List<Integer> replicas, int brokerId, Uuid topicId, UnifiedLog log) {


There is no need to pass in topicId since it comes from log.

Good call. Fixed

mimaison · 2025-09-02T16:09:13Z

Rebased on trunk, @jsancio @junrao can you take another look? Thanks

mimaison · 2025-09-09T09:50:35Z

Rebased on trunk to resolve conflicts

mimaison · 2025-09-16T19:16:41Z

Rebased once more. @jsancio @junrao can you take another look? Thanks

mimaison · 2025-09-29T14:23:33Z

@jsancio @junrao I keep rebasing this each week. Quick reminder, can you take another look? Thanks

mimaison · 2025-12-03T17:32:25Z

@jsancio @junrao Do you want to take another look? Or should I go ahead and merge it?

github-actions bot added core Kafka Broker kraft storage Pull requests that target the storage module build Gradle build or GitHub Actions labels May 19, 2025

ijuma reviewed May 23, 2025

View reviewed changes

dengziming reviewed May 29, 2025

View reviewed changes

brandboat reviewed May 29, 2025

View reviewed changes

mimaison force-pushed the kafka-15599-4 branch from d03cffd to bdc03b0 Compare June 11, 2025 10:39

dengziming approved these changes Jun 19, 2025

View reviewed changes

mimaison requested a review from junrao June 25, 2025 08:45

junrao reviewed Jul 1, 2025

View reviewed changes

github-actions bot added tools connect performance mirror-maker-2 clients labels Jul 2, 2025

mimaison force-pushed the kafka-15599-4 branch from 6b18fee to 1d7e5b8 Compare July 2, 2025 14:05

junrao reviewed Jul 3, 2025

View reviewed changes

junrao reviewed Jul 7, 2025

View reviewed changes

jsancio reviewed Jul 7, 2025

View reviewed changes

mimaison force-pushed the kafka-15599-4 branch from b3f537a to 9aa6e5e Compare July 29, 2025 19:29

junrao reviewed Aug 13, 2025

View reviewed changes

mimaison force-pushed the kafka-15599-4 branch from 81a8925 to 96f6c9d Compare August 25, 2025 10:13

mimaison force-pushed the kafka-15599-4 branch from 96f6c9d to adee6d1 Compare September 2, 2025 16:07

mimaison force-pushed the kafka-15599-4 branch from adee6d1 to 509f808 Compare September 9, 2025 09:49

mimaison force-pushed the kafka-15599-4 branch from 509f808 to c7b7a6c Compare September 16, 2025 10:22

mimaison force-pushed the kafka-15599-4 branch from c7b7a6c to b3680a8 Compare September 29, 2025 10:22

mimaison force-pushed the kafka-15599-4 branch from b3680a8 to c09095b Compare October 14, 2025 13:44

mimaison force-pushed the kafka-15599-4 branch from c09095b to ed53125 Compare October 24, 2025 13:32

mimaison mentioned this pull request Nov 3, 2025

KAFKA-19301: Move and rewrite partition state classes to Java in org.apache.kafka.storage.internals.log #20083

Merged

mimaison force-pushed the kafka-15599-4 branch from ed53125 to c250ac3 Compare December 2, 2025 11:51

mimaison and others added 9 commits December 16, 2025 11:04

KAFKA-15599: Move KafkaMetadataLog to the raft module

1f79590

Rename ReplicatedLog to RaftLog

bd761ce

Address feedback from Ziming

1e506cf

Address feedback from Jun

6ff4840

Address 2nd review from Jun

211a410

Handle NoSuchFileException in readSnapshot()

21247db

Keep extra logic in TopicsImage to a minimum

431dc6f

Move KafkaRaftLog to internals package

10a356f

Remove topicId argument from isStrayReplica

6578051

mimaison force-pushed the kafka-15599-4 branch from c250ac3 to 6578051 Compare December 16, 2025 10:14

mimaison merged commit bf91c07 into apache:trunk Dec 16, 2025
20 checks passed

mimaison deleted the kafka-15599-4 branch December 16, 2025 12:51

KAFKA-15599: Move KafkaMetadataLog to the raft module #19762

KAFKA-15599: Move KafkaMetadataLog to the raft module #19762

Uh oh!

Conversation

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

Uh oh!

Uh oh!

dengziming commented May 21, 2025

Uh oh!

mimaison commented May 21, 2025

Uh oh!

dengziming commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mimaison commented May 22, 2025

Uh oh!

dengziming commented May 23, 2025

Uh oh!

ijuma commented May 23, 2025

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!

dengziming left a comment

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!

ijuma May 29, 2025 • 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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brandboat May 29, 2025 • 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!

dengziming 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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

mimaison commented May 19, 2025 •

edited by github-actions bot

Loading

dengziming commented May 22, 2025 •

edited

Loading

ijuma May 29, 2025 •

edited

Loading

brandboat May 29, 2025 •

edited

Loading