KAFKA-18884: Move TransactionMetadata to transaction-coordinator module by FrankYang0529 · Pull Request #19699 · apache/kafka

FrankYang0529 · 2025-05-13T04:36:35Z

Move TransactionMetadata to transaction-coordinator module.
Rewrite TransactionMetadata in Java.
The topicPartitions field uses HashSet instead of Set, because
it's mutable field.
In Scala, when calling prepare* methods, they can use current value
as default input in prepareTransitionTo. However, in Java, it doesn't
support function default input value. To avoid a lot of duplicated code
or assign value to wrong field, we add a private class TransitionData.
It can get current TransactionMetadata value as default value and
prepare* methods just need to assign updated value.

Reviewers: Justine Olshan jolshan@confluent.io, Artem Livshits
alivshits@confluent.io, Chia-Ping Tsai chia7712@gmail.com

Signed-off-by: PoAn Yang <payang@apache.org>

chia7712 · 2025-05-19T14:55:22Z

          // the authorization check to indicate that they were not added to the transaction.
          val partitionErrors = unauthorizedTopicErrors ++ nonExistingTopicErrors ++
-            authorizedPartitions.map(_ -> Errors.OPERATION_NOT_ATTEMPTED)
+            authorizedPartitions.stream().map(_ -> Errors.OPERATION_NOT_ATTEMPTED).toList.asScala.toSeq


toSeq is redundant, right?

chia7712 · 2025-05-19T15:03:47Z

+        );
+    }
+
+    public Either<Errors, TxnTransitMetadata> prepareIncrementProducerEpoch(


it can throw exception and callers can convert the exception to error. we don't need to introduce Either I think

Signed-off-by: PoAn Yang <payang@apache.org>

FrankYang0529 · 2025-05-20T15:03:20Z

@chia7712, I addressed all comments. Could you review again when you have time? Thanks.

chia7712

@FrankYang0529 thanks for this patch

chia7712 · 2025-05-23T14:14:57Z

+            throw new IllegalStateException("Cannot allocate any more producer epochs for producerId " + producerId);
+
+        short bumpedEpoch = (short) (producerEpoch + 1);
+        Short produceEpochResult;


chia7712 · 2025-05-23T14:15:01Z

+
+        short bumpedEpoch = (short) (producerEpoch + 1);
+        Short produceEpochResult;
+        Short lastProducerEpochResult;


chia7712 · 2025-05-23T14:16:39Z

                  TransactionState.PREPARE_ABORT

-                if (nextState == TransactionState.PREPARE_ABORT && txnMetadata.pendingState.contains(TransactionState.PREPARE_EPOCH_FENCE)) {
+                if (nextState == TransactionState.PREPARE_ABORT && txnMetadata.pendingState.isPresent && txnMetadata.pendingState.get.equals(TransactionState.PREPARE_EPOCH_FENCE)) {


txnMetadata.pendingState.filter(s => s == TransactionState.PREPARE_EPOCH_FENCE).isPresent)

chia7712 · 2025-05-23T14:20:11Z

            } else {
-              txnMetadata.prepareIncrementProducerEpoch(transactionTimeoutMs, expectedProducerIdAndEpoch.map(_.epoch),
-                time.milliseconds())
+              try {


try { if (txnMetadata.isProducerEpochExhausted && expectedProducerIdAndEpoch.forall(_.epoch == txnMetadata.producerEpoch)) Right(txnMetadata.prepareProducerIdRotation(producerIdManager.generateProducerId(), transactionTimeoutMs, time.milliseconds(), expectedProducerIdAndEpoch.isDefined)) else Right(txnMetadata.prepareIncrementProducerEpoch(transactionTimeoutMs, expectedProducerIdAndEpoch.map(e => Short.box(e.epoch)).toJava, time.milliseconds())) } catch { case e: Exception => Left(Errors.forException(e)) }

chia7712 · 2025-05-23T14:22:32Z

            // PrepareEpochFence has slightly different epoch bumping logic so don't include it here.
            // Note that, it can only happen when the current state is Ongoing.
-            isEpochFence = txnMetadata.pendingState.contains(TransactionState.PREPARE_EPOCH_FENCE)
+            isEpochFence = txnMetadata.pendingState.isPresent && txnMetadata.pendingState.get.equals(TransactionState.PREPARE_EPOCH_FENCE)


txnMetadata.pendingState.filter(s => s == TransactionState.PREPARE_EPOCH_FENCE).isPresent

chia7712 · 2025-05-23T14:23:55Z

+              txnMetadata.inLock(() => {
                if (txnMetadataCacheEntry.coordinatorEpoch == idCoordinatorEpochAndMetadata.coordinatorEpoch
-                  && txnMetadata.pendingState.contains(TransactionState.DEAD)
+                  && txnMetadata.pendingState.isPresent && txnMetadata.pendingState.get.equals(TransactionState.DEAD)


txnMetadata.pendingState.filter(s => s == TransactionState.DEAD).isPresent

chia7712 · 2025-05-23T14:29:44Z

          // the authorization check to indicate that they were not added to the transaction.
          val partitionErrors = unauthorizedTopicErrors ++ nonExistingTopicErrors ++
-            authorizedPartitions.map(_ -> Errors.OPERATION_NOT_ATTEMPTED)
+            authorizedPartitions.stream().map(_ -> Errors.OPERATION_NOT_ATTEMPTED).toList.asScala


authorizedPartitions.asScala.map(_ -> Errors.OPERATION_NOT_ATTEMPTED)

chia7712 · 2025-05-23T14:30:09Z

+    private volatile long txnStartTimestamp;
+    private volatile long txnLastUpdateTimestamp;
+    private TransactionVersion clientTransactionVersion;
+    private static final Logger LOGGER = LoggerFactory.getLogger(TransactionMetadata.class);


move it to line#38

Signed-off-by: PoAn Yang <payang@apache.org>

FrankYang0529 · 2025-05-24T09:57:00Z

@chia7712 Thanks for the suggestion. I address all comments.

chia7712

@FrankYang0529 thanks for this patch. a couple of comments are left. PTAL

chia7712 · 2025-07-07T23:57:33Z

+        short producerEpoch = TransactionMetadata.this.producerEpoch;
+        short lastProducerEpoch = TransactionMetadata.this.lastProducerEpoch;
+        int txnTimeoutMs = TransactionMetadata.this.txnTimeoutMs;
+        Set<TopicPartition> topicPartitions = Set.copyOf(TransactionMetadata.this.topicPartitions);


not sure why a deep copy is necessary?

chia7712 · 2025-07-07T23:58:47Z

+    public TxnTransitMetadata prepareNoTransit() {
+        // do not call transitTo as it will set the pending state, a follow-up call to abort the transaction will set its pending state
+        return new TxnTransitMetadata(producerId, prevProducerId, nextProducerId, producerEpoch, lastProducerEpoch, txnTimeoutMs,
+            state, new HashSet<>(topicPartitions), txnStartTimestamp, txnLastUpdateTimestamp, clientTransactionVersion);


Set.copyOf

chia7712 · 2025-07-08T00:03:06Z

+            // In the case of a new producer, producerEpoch will be -1 and bumpedEpoch will be 0
+            produceEpochResult = bumpedEpoch;
+            lastProducerEpochResult = RecordBatch.NO_PRODUCER_EPOCH;
+        } else {


please flatten it.

var data = new TransitionData(TransactionState.EMPTY); short bumpedEpoch = (short) (producerEpoch + 1); if (expectedProducerEpoch.isEmpty()) { // If no expected epoch was provided by the producer, bump the current epoch and set the last epoch to -1 // In the case of a new producer, producerEpoch will be -1 and bumpedEpoch will be 0 data.producerEpoch = bumpedEpoch; data.lastProducerEpoch = RecordBatch.NO_PRODUCER_EPOCH; } else if (producerEpoch == RecordBatch.NO_PRODUCER_EPOCH || expectedProducerEpoch.get() == producerEpoch) { // If the expected epoch matches the current epoch, or if there is no current epoch, the producer is attempting // to continue after an error and no other producer has been initialized. Bump the current and last epochs. // The no current epoch case means this is a new producer; producerEpoch will be -1 and bumpedEpoch will be 0 data.producerEpoch = bumpedEpoch; data.lastProducerEpoch = producerEpoch; } else if (expectedProducerEpoch.get() == lastProducerEpoch) { // If the expected epoch matches the previous epoch, it is a retry of a successful call, so just return the // current epoch without bumping. There is no danger of this producer being fenced, because a new producer // calling InitProducerId would have caused the last epoch to be set to -1. // Note that if the IBP is prior to 2.4.IV1, the lastProducerId and lastProducerEpoch will not be written to // the transaction log, so a retry that spans a coordinator change will fail. We expect this to be a rare case. data.producerEpoch = producerEpoch; data.lastProducerEpoch = lastProducerEpoch; } else { // Otherwise, the producer has a fenced epoch and should receive an PRODUCER_FENCED error LOGGER.info("Expected producer epoch {} does not match current producer epoch {} or previous producer epoch {}", expectedProducerEpoch.get(), producerEpoch, lastProducerEpoch); throw Errors.PRODUCER_FENCED.exception(); } data.txnTimeoutMs = newTxnTimeoutMs; data.topicPartitions = Set.of(); data.txnStartTimestamp = -1L; data.txnLastUpdateTimestamp = updateTimestamp;

chia7712 · 2025-07-08T00:06:35Z

+                                                   long nextProducerId,
+                                                   long updateTimestamp,
+                                                   boolean noPartitionAdded) {
+        short updatedProducerEpoch;


var data = new TransitionData(newState); if (clientTransactionVersion.supportsEpochBump()) { // We already ensured that we do not overflow here. MAX_SHORT is the highest possible value. data.producerEpoch = (short) (producerEpoch + 1); data.lastProducerEpoch = producerEpoch; } else { data.producerEpoch = producerEpoch; data.lastProducerEpoch = lastProducerEpoch; } // With transaction V2, it is allowed to abort the transaction without adding any partitions. Then, the transaction // start time is uncertain but it is still required. So we can use the update time as the transaction start time. data.txnStartTimestamp = noPartitionAdded ? updateTimestamp : txnStartTimestamp; data.nextProducerId = nextProducerId; data.txnLastUpdateTimestamp = updateTimestamp; data.clientTransactionVersion = clientTransactionVersion; return prepareTransitionTo(data);

chia7712 · 2025-07-08T00:07:38Z

+    }
+
+    public TxnTransitMetadata prepareComplete(long updateTimestamp) {
+        TransactionState newState = state == TransactionState.PREPARE_COMMIT ?


// Since the state change was successfully written to the log, unset the flag for a failed epoch fence hasFailedEpochFence = false; var data = new TransitionData(state == TransactionState.PREPARE_COMMIT ? TransactionState.COMPLETE_COMMIT : TransactionState.COMPLETE_ABORT); // In the prepareComplete transition for the overflow case, the lastProducerEpoch is kept at MAX-1, // which is the last epoch visible to the client. // Internally, however, during the transition between prepareAbort/prepareCommit and prepareComplete, the producer epoch // reaches MAX but the client only sees the transition as MAX-1 followed by 0. // When an epoch overflow occurs, we set the producerId to nextProducerId and reset the epoch to 0, // but lastProducerEpoch remains MAX-1 to maintain consistency with what the client last saw. if (clientTransactionVersion.supportsEpochBump() && nextProducerId != RecordBatch.NO_PRODUCER_ID) { data.producerId = nextProducerId; data.producerEpoch = 0; } else { data.producerId = producerId; data.producerEpoch = producerEpoch; } data.nextProducerId = RecordBatch.NO_PRODUCER_ID; data.topicPartitions = Set.of(); data.txnLastUpdateTimestamp = updateTimestamp; return prepareTransitionTo(data);

chia7712 · 2025-07-08T00:11:50Z

+        long transitProducerId = transitMetadata.producerId();
+        short transitLastProducerEpoch = transitMetadata.lastProducerEpoch();
+
+        if (isAtLeastTransactionsV2 &&


if (isAtLeastTransactionsV2 && (txnState == TransactionState.COMPLETE_COMMIT || txnState == TransactionState.COMPLETE_ABORT) && transitProducerEpoch == 0) { return transitLastProducerEpoch == lastProducerEpoch && transitMetadata.prevProducerId() == producerId; } if (isAtLeastTransactionsV2 && (txnState == TransactionState.PREPARE_COMMIT || txnState == TransactionState.PREPARE_ABORT)) { return transitLastProducerEpoch == producerEpoch && transitProducerId == producerId; } return transitProducerEpoch == producerEpoch && transitProducerId == producerId;

chia7712 · 2025-07-08T00:14:07Z

+        return txnLastUpdateTimestamp;
+    }
+
+    public void setClientTransactionVersion(TransactionVersion clientTransactionVersion) {


Could we remove the prefix set?

chia7712 · 2025-07-08T00:17:24Z

    assertEquals(0, channelManager.numTxnsWithPendingMarkers)
    assertEquals(0, channelManager.queueForBroker(broker1.id).get.totalNumMarkers)
-    assertEquals(None, txnMetadata2.pendingState)
+    assertTrue(txnMetadata2.pendingState.isEmpty)


assertEquals(Optional.empty(), txnMetadata2.pendingState)

chia7712 · 2025-07-08T00:17:35Z

    assertEquals(0, channelManager.numTxnsWithPendingMarkers)
    assertEquals(0, channelManager.queueForBroker(broker1.id).get.totalNumMarkers)
-    assertEquals(None, txnMetadata2.pendingState)
+    assertTrue(txnMetadata2.pendingState.isEmpty)


assertEquals(Optional.empty(), txnMetadata2.pendingState)

chia7712 · 2025-07-08T00:17:40Z

    assertEquals(0, channelManager.numTxnsWithPendingMarkers)
    assertEquals(0, channelManager.queueForBroker(broker1.id).get.totalNumMarkers)
-    assertEquals(None, txnMetadata2.pendingState)
+    assertTrue(txnMetadata2.pendingState.isEmpty)


Signed-off-by: PoAn Yang <payang@apache.org>

jolshan · 2025-08-06T19:08:42Z

@FrankYang0529 @chia7712 How are things going here? I can help review if we need to get it over the line.

cc: @artemlivshits @rreddy-22

FrankYang0529 · 2025-08-07T14:19:59Z

I just merged trunk, but CI cannot pass. I need some time to fix these. Thanks.

Signed-off-by: PoAn Yang <payang@apache.org>

chia7712

@FrankYang0529 thanks for this patch. I have a couple of questions. Please take a look

chia7712 · 2025-08-07T17:56:25Z

+        return pendingState.isPresent();
+    }
+
+    public ReentrantLock lock() {


Could we avoid exposing the lock, even during testing?

chia7712 · 2025-08-07T18:03:48Z

+            producerEpoch = transitMetadata.producerEpoch();
+            lastProducerEpoch = transitMetadata.lastProducerEpoch();
+            txnTimeoutMs = transitMetadata.txnTimeoutMs();
+            topicPartitions = transitMetadata.topicPartitions();


Line#135 uses Set.copyOf to create an immutable copy, which makes topicPartitions immutable. This could potentially lead a bug.

Perhaps we should use a HashSet instead to ensure mutability

chia7712 · 2025-08-07T18:11:27Z

+                " while it already a pending state " + pendingState.get());
+
+        if (data.producerId < 0)
+            throw new IllegalArgumentException("Illegal new producer id " + producerId);


producerId -> data.producerId

chia7712 · 2025-08-07T18:15:31Z

+        if (data.state.validPreviousStates().contains(this.state)) {
+            TxnTransitMetadata transitMetadata = new TxnTransitMetadata(
+                data.producerId, this.producerId, data.nextProducerId, data.producerEpoch, data.lastProducerEpoch,
+                data.txnTimeoutMs, data.state, new HashSet<>(data.topicPartitions),


I have another comment related to this immutability. If you intend to keep TxnTransitMetadata#topicPartitions mutable, then line#135 should use a HashSet instead of Set.copyOf, since the latter creates a immutable set

chia7712 · 2025-08-07T18:21:38Z

+                " completing transaction state transition while it does not have a pending state");
+        });
+
+        if (!toState.equals(transitMetadata.txnState())) {


if (!toState.equals(transitMetadata.txnState())) throwStateTransitionFailure(transitMetadata); switch (toState) {

jolshan · 2025-08-07T21:28:33Z

+        // is created for the first time and it could stay like this until transitioning
+        // to Dead.
+        if (data.state != TransactionState.DEAD && data.producerEpoch < 0)
+            throw new IllegalArgumentException("Illegal new producer epoch " + producerEpoch);


this one is also data.producerEpoch?

jolshan · 2025-08-07T21:33:56Z

+        );
+    }
+
+    private class TransitionData {


Can we have some javadoc here explaining how this class is used?

jolshan · 2025-08-07T21:37:56Z

Thanks for the PR!
Can we update the description a bit to explain some of the changes? Like specifically how the state transitions work with the java class. In scala, we could convert to transit metadata from transaction metadata by using the methods that only changed the values we needed. If we could briefly sketch how this works in the new model, that would help.

Signed-off-by: PoAn Yang <payang@apache.org>

chia7712

@FrankYang0529 thanks for updates.

chia7712 · 2025-08-10T17:02:09Z

        TransactionState txnState,
-        Set<TopicPartition> topicPartitions,
+        // The TransactionMetadata#topicPartitions field is mutable.
+        // To avoid deepcopy when assigning value from TxnTransitMetadata to TransactionMetadata, use HashSet here.


deep copy

chia7712 · 2025-08-10T17:09:41Z

+        if (data.state.validPreviousStates().contains(this.state)) {
+            TxnTransitMetadata transitMetadata = new TxnTransitMetadata(
+                data.producerId, this.producerId, data.nextProducerId, data.producerEpoch, data.lastProducerEpoch,
+                data.txnTimeoutMs, data.state, new HashSet<>(data.topicPartitions),


are we not sure if this set should be mutable or not?

We discussed whether TxnTransitMetadata should hold a reference to topicPartitions or perform a deep copy. I prefer to keep the original behavior of holding the reference

val transitMetadata = new TxnTransitMetadata(producerId, this.producerId, nextProducerId, producerEpoch, lastProducerEpoch, txnTimeoutMs, state, // no deep copy topicPartitions.asJava, txnStartTimestamp, txnLastUpdateTimestamp, clientTransactionVersion)

@FrankYang0529 WDYT?

Signed-off-by: PoAn Yang <payang@apache.org>

jolshan

Seems like all comments were addressed. @chia7712 let me know if you see anything missing.

chia7712 · 2025-08-15T18:09:30Z

I open https://issues.apache.org/jira/browse/KAFKA-19609 to move the related tests to transaction-coordinator module

chia7712 · 2025-08-15T18:18:21Z

+        this.lastProducerEpoch = lastProducerEpoch;
+        this.txnTimeoutMs = txnTimeoutMs;
+        this.state = state;
+        this.topicPartitions = new HashSet<>(topicPartitions);


Since topicPartitions is always empty in production when creating TransactionMetadata, we could remove it from the constructor to simplify the code

@chia7712 Thanks for the suggestion. I create a followup PR for it. #20370

chia7712 · 2025-08-15T18:43:26Z

+import java.util.HashSet;

 /**
 * Immutable object representing the target transition of the transaction metadata


Immutable is no longer correct. Could you please update it in the follow-up?

…tionMetadata with non-empty topic partitions (#20370) This is followup PR for #19699. * Update TransactionLog#readTxnRecordValue to initialize TransactionMetadata with non-empty topic partitions * Update `TxnTransitMetadata` comment, because it's not immutable. Reviewers: TengYao Chi <kitingiao@gmail.com>, Justine Olshan <jolshan@confluent.io>, Kuan-Po Tseng <brandboat@gmail.com>, Chia-Ping Tsai <chia7712@gmail.com>

…tionMetadata with non-empty topic partitions (apache#20370) This is followup PR for apache#19699. * Update TransactionLog#readTxnRecordValue to initialize TransactionMetadata with non-empty topic partitions * Update `TxnTransitMetadata` comment, because it's not immutable. Reviewers: TengYao Chi <kitingiao@gmail.com>, Justine Olshan <jolshan@confluent.io>, Kuan-Po Tseng <brandboat@gmail.com>, Chia-Ping Tsai <chia7712@gmail.com>

KAFKA-18884: Move TransactionMetadata to transaction-coordinator module

26e1a49

Signed-off-by: PoAn Yang <payang@apache.org>

github-actions Bot added core Kafka Broker transactions Transactions and EOS clients labels May 13, 2025

FrankYang0529 added the ci-approved label May 13, 2025

FrankYang0529 added 2 commits May 17, 2025 15:11

KAFAK-18884: remove some java / scala transformation

ece6ef9

Signed-off-by: PoAn Yang <payang@apache.org>

Merge branch 'trunk' into KAFKA-18884

8e9afc2

FrankYang0529 changed the title ~~KAFKA-18884: Move TransactionMetadata to transaction-coordinator module (wip)~~ KAFKA-18884: Move TransactionMetadata to transaction-coordinator module May 17, 2025

FrankYang0529 requested a review from chia7712 May 17, 2025 16:04

chia7712 reviewed May 19, 2025

View reviewed changes

FrankYang0529 added 2 commits May 20, 2025 19:38

Merge branch 'trunk' into KAFKA-18884

0bee440

address comment

c1f2485

Signed-off-by: PoAn Yang <payang@apache.org>

FrankYang0529 requested a review from chia7712 May 20, 2025 15:03

chia7712 reviewed May 23, 2025

View reviewed changes

FrankYang0529 added 4 commits May 23, 2025 23:45

Merge branch 'trunk' into KAFKA-18884

180881c

address comment

703ea8a

Signed-off-by: PoAn Yang <payang@apache.org>

remove unused function

53c61b7

Signed-off-by: PoAn Yang <payang@apache.org>

Merge branch 'trunk' into KAFKA-18884

ff335a1

FrankYang0529 requested a review from chia7712 May 24, 2025 09:56

FrankYang0529 added 9 commits May 25, 2025 21:07

Merge branch 'trunk' into KAFKA-18884

abaa206

Merge branch 'trunk' into KAFKA-18884

c39b9b5

Merge branch 'trunk' into KAFKA-18884

97bc2a5

Merge branch 'trunk' into KAFKA-18884

3edd06e

Merge branch 'trunk' into KAFKA-18884

1d12df5

Merge branch 'trunk' into KAFKA-18884

e65d6e3

Merge branch 'trunk' into KAFKA-18884

962934c

Merge branch 'trunk' into KAFKA-18884

119d7d0

Merge branch 'trunk' into KAFKA-18884

c7f95e6

Merge branch 'trunk' into KAFKA-18884

11b175f

chia7712 reviewed Jul 8, 2025

View reviewed changes

FrankYang0529 added 4 commits July 8, 2025 21:48

Merge branch 'trunk' into KAFKA-18884

e4dd2c2

address comment

66b58c5

Signed-off-by: PoAn Yang <payang@apache.org>

Merge branch 'trunk' into KAFKA-18884

7eff967

Merge branch 'trunk' into KAFKA-18884

c5a3791

Merge branch 'trunk' into KAFKA-18884

f80e9ab

fix: change TransactionMetadata class path in spotbugs-exclude.xml

a0f379c

Signed-off-by: PoAn Yang <payang@apache.org>

github-actions Bot added the build Gradle build or GitHub Actions label Aug 7, 2025

chia7712 reviewed Aug 7, 2025

View reviewed changes

jolshan reviewed Aug 7, 2025

View reviewed changes

FrankYang0529 added 3 commits August 8, 2025 22:38

feat: change topicPartitions from Set to HashSet

f7f0687

Signed-off-by: PoAn Yang <payang@apache.org>

Merge branch 'trunk' into KAFKA-18884

356b47e

feat: change topicPartitions from Set to HashSet

2ade564

Signed-off-by: PoAn Yang <payang@apache.org>

chia7712 reviewed Aug 10, 2025

View reviewed changes

FrankYang0529 added 2 commits August 11, 2025 14:26

Merge branch 'trunk' into KAFKA-18884

eacf843

address comment

fd10a55

Signed-off-by: PoAn Yang <payang@apache.org>

jolshan approved these changes Aug 14, 2025

View reviewed changes

chia7712 approved these changes Aug 15, 2025

View reviewed changes

chia7712 merged commit 990cb5c into apache:trunk Aug 15, 2025
24 checks passed

chia7712 reviewed Aug 15, 2025

View reviewed changes

FrankYang0529 deleted the KAFKA-18884 branch August 16, 2025 02:26

FrankYang0529 mentioned this pull request Aug 18, 2025

MINOR: update TransactionLog#readTxnRecordValue to initialize TransactionMetadata with non-empty topic partitions #20370

Merged

Uh oh!

Conversation

FrankYang0529 commented May 13, 2025 • edited by github-actions Bot 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!

Choose a reason for hiding this comment

Uh oh!

FrankYang0529 commented May 20, 2025

Uh oh!

chia7712 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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FrankYang0529 commented May 24, 2025

Uh oh!

chia7712 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

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 Aug 6, 2025

Uh oh!

FrankYang0529 commented Aug 7, 2025

Uh oh!

chia7712 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

Uh oh!

jolshan commented Aug 7, 2025

Uh oh!

chia7712 left a comment

Choose a reason for hiding this comment

FrankYang0529 commented May 13, 2025 •

edited by github-actions Bot

Loading