KAFKA-17019: Producer TimeoutException should include root cause #20159

chickenchickenlove · 2025-07-12T00:56:33Z

Changes

Add new Exception class PotentialCauseException.
All org.apache.kafka.common.errors.TimeoutException in
KafkaProducer has PotentialCauseException as root cause if it
cannot catch any exception.

Describe

TimeoutException can be thrown for various reasons.
However, it is often difficult to identify the root cause,
Because there are so many potential factors that can lead to a
TimeoutException.

For example:

The ProducerClient might be busy, so it may not be able to send the
request in time. As a result, some batches may expire, leading to a
TimeoutException.
The broker might be unavailable due to network issues or internal
failures.
A request may be in flight, and although the broker successfully
handles and responds to it, the response might arrive slightly late.

As shown above, there are many possible causes. In some cases, no
exception is caught in the catch block, and a TimeoutException is
thrown simply by comparing the elapsed time. However, the developer
using TimeoutException in KafkaProducer likely already knows which
specific reasons could cause it in that context. Therefore, I think it
would be helpful to include a PotentialCauseException that reflects
the likely reason, based on the developer’s knowledge.

Reviewers: TengYao Chi kitingiao@gmail.com, Yung
yungyung7654321@gmail.com, Andrew Schofield
aschofield@confluent.io, Chia-Ping Tsai chia7712@gmail.com

frankvicky

@chickenchickenlove: Thanks for the patch.

frankvicky · 2025-07-12T08:23:27Z

...ts/src/main/java/org/apache/kafka/clients/producer/internals/TransactionalRequestResult.java

+        this.await(timeout, unit, null);
+    }
+
+    public void await(long timeout, TimeUnit unit, PotentialCauseException potentialCauseException) {


Could we change PotentialCauseException to Supplier<PotentialCauseException>?
Creating an exception instance is very expensive; lazy creation could help us avoid this situation.

Thanks for your comments and sounds great!
I have addressed PR review.
When you have time, please take another look. 🙇‍♂️

AndrewJSchofield · 2025-07-14T14:33:32Z

Thanks for the PR. Because you've created a new public exception class org.apache.kafka.common.errors.PotentialCauseException, I think you'll need a KIP. Coincidentally, I am trying to track down a bogus TimeoutException to fix an issue in the producer :)

chia7712

@chickenchickenlove thanks for this patch. one major comment is left. Please take a a look

chia7712 · 2025-07-14T21:27:27Z

clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java

-                throw new TimeoutException(errorMessage);
+                if (ex.getCause() != null)
+                    throw new TimeoutException(errorMessage, ex.getCause());
+                throw new TimeoutException(errorMessage, new PotentialCauseException("Metadata update timed out ― topic missing, auth denied, broker/partition unavailable, or client sender/buffer stalled."));


It seems PotentialCauseException does not offer more useful information than the error message, right? Perhaps we could enrich the error message instead of introducing a new nonspecific exception

@chia7712 thanks for your comment. 🙇‍♂️
I agree your opinion especially that 'we could enrich the error message instead of introducing a new nonspecific exception'.
However, Introducing a new nonspecific exception to solve this issue has has pros and cons.

Let me explain more.

The KAFKA-17019 requires that all org.apache.kafka.common.errors.TimeoutException should include root cause as a nested exception.

It’s hard to pinpoint the root cause in every situation where a TimeoutException occurs

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

Lines 405 to 418 in c6cf517

accumulator.resetNextBatchExpiryTime();

List<ProducerBatch> expiredInflightBatches = getExpiredInflightBatches(now);

List<ProducerBatch> expiredBatches = this.accumulator.expiredBatches(now);

expiredBatches.addAll(expiredInflightBatches);

// Reset the producer id if an expired batch has previously been sent to the broker. Also update the metrics

// for expired batches. see the documentation of @TransactionState.resetIdempotentProducerId to understand why

// we need to reset the producer id here.

if (!expiredBatches.isEmpty())

log.trace("Expired {} batches in accumulator", expiredBatches.size());

for (ProducerBatch expiredBatch : expiredBatches) {

String errorMessage = "Expiring " + expiredBatch.recordCount + " record(s) for " + expiredBatch.topicPartition

+ ":" + (now - expiredBatch.createdMs) + " ms has passed since batch creation";

failBatch(expiredBatch, new TimeoutException(errorMessage), false);

In here, expiredInflightBatches and expiredBatches can cause TimeoutException.
However, TimeoutException is thrown as a result of calculating elapsed time.
Therefore, expiredInflightBatches and expiredBatches don't have information about root cause.

If expiredInflight encounters some problem --

Normal Case - No errors and succeed.

Network Issue - Error might occurs after the expired period.

a little bit slow network issue because of Bandwidth, and so on. - No errors and slow response.

Busy CPU due to various reasons - No errors and called slowly.

There are many possible scenarios where a TimeoutException can occur, even with a simple analysis.
However, the expiredInFlight instance can actually throw an error in only 2 (Maybe connection closed, fail to establish connection, ...)

After spending a considerable amount of time reviewing the code and analyzing the TimeoutExceptions thrown by the Producer, I concluded that it's difficult to extract the root cause at every point where a TimeoutException is created.

Idea + Pros and Cons

Developers usually have a good understanding of what kind of error might occur in a given context.
Therefore, in cases where it's difficult to catch the actual root cause, it's possible to include an expected exception as the root cause instead.

Here’s a summary of the pros and cons (compared to simply enhancing the error message):

pros : At call sites(For example, kafka streams, kafka connect, kafka producer internal and so on) where a TimeoutException is expected, the root cause can be used to handle different cases conditionally.

For example, you could create NetworkPotentialCauseException and CPUBusyPotentialCauseException as subclasses of PotentialCauseException, and handle different branches based on the root cause—branch A if the root cause is a NetworkPotentialCauseException, and branch B if it’s a CPUBusyPotentialCauseException.

cons : Higher instance creation cost compared to String instance.

I spent quite a bit of time thinking through the direction of this PR.
What are your thoughts on it?
Please let me know. 🙇‍♂️

thanks for your explanation. I agree that specific exception types could help developer to catch the actual root cause. My question is, do we really need PotentialCauseException to be the base exception for NetworkPotentialCauseException and CPUBusyPotentialCauseException? Perhaps KafkaException is good enough.

Another exception design uses TimeoutException as a parent class, similar to e032a36. The benefit of this is simplifying the code, since developers wouldn't need to check root cause of a TimeoutException from root cause of an ExecutionException 😄

thanks for bringing up this great discussion. I'd like to see kafka exception hierarchy becomr more developer-friendly.

@chia7712
Thank you for considering my proposal and for sharing your valuable thoughts.
As you mentioned, I also think it’s a good idea to reuse an existing Exception class.

Personally, I think using KafkaException would be a better approach.
Since there can be multiple potential causes for a TimeoutException in certain code paths, it might be difficult to pinpoint the exact cause. In such cases, it could be unclear which subclass of TimeoutException should be used. (e032a36)

So, my suggestion is as follows:

Include a KafkaException as the root cause of the TimeoutException, and describe the possible scenario in the error message of the KafkaException.

Let the detailed error information be available via the root cause of the TimeoutException.

Keep the current message format of the TimeoutException itself (which currently only includes the elapsed time before it expired).

I’m thinking of revising the PR in this direction.

This way, I believe we can preserve the current semantics of TimeoutException while still conveying helpful contextual information (such as a potential cause) when necessary.
In the future, if there's a need to branch logic based on a more specific cause of the timeout—even if no actual exception was thrown—then the developer could define a concrete PotentialCauseException class as needed.

Also, if this direction sounds reasonable, I think it wouldn’t require a KIP change.

What do you think?
Please share your opinion 🙇‍♂️

The proposal of reusing KafkaException sounds good. +1 to it.

Sounds good to me also. There's no need to create a KIP for this approach and it gives just as much information to the user.

chickenchickenlove · 2025-07-14T22:44:53Z

@AndrewJSchofield Thanks for your comments 🙇‍♂️
I'm new to make a KIP.
I have one question!

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
Should I just go ahead and create a KIP document here?
Once it’s created, will other committers, contributors, and users join the discussion by leaving comments, and then we can proceed with the discussion from there?

Thanks in advance!

AndrewJSchofield · 2025-07-15T06:30:47Z

@AndrewJSchofield Thanks for your comments 🙇‍♂️ I'm new to make a KIP. I have one question!

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals Should I just go ahead and create a KIP document here? Once it’s created, will other committers, contributors, and users join the discussion by leaving comments, and then we can proceed with the discussion from there?

Thanks in advance!

Yes, that's right. You would follow the instructions in that wiki page and make a new KIP using the template. The discussion would proceed on the dev mailing list. For an interesting KIP, the community will generally not need any encouragement to get involved in the discussion.

chickenchickenlove · 2025-07-19T13:39:37Z

@chia7712 @AndrewJSchofield @frankvicky Hi!
I made a new commit to address PR review.
When you have time, Please take another look. 🙇‍♂️

chickenchickenlove · 2025-07-27T09:02:01Z

@chia7712 @AndrewJSchofield @frankvicky
Sorry to bother you.
When you have time, Please take another look 🙇‍♂️

AndrewJSchofield

Thanks for the update. I think this is a good idea, but the consistency of the error messages could be better. I suggest defining something like:

private static final String INIT_TRANSACTIONS_TIME_OUT_MESSAGE = "InitTransactions timed out – could not discover the transaction coordinator or receive the InitProducerId response within max.block.ms (broker unavailable, network lag, or ACL denial).";

and the same for the other new error strings.

Then, you'll find it easier to use the same form for things like "ACL" and "ACL denial" and "ACL issue" and "auth denial" which I guess are all the same thing just written differently, and hard to see because the strings are spread across the code.

Yunyung

Thanks for the PR. Some comments left. Also, could you add tests to validate that the messages are thrown correctly as expected?

Yunyung · 2025-08-03T18:59:18Z

clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java

            } catch (TimeoutException ex) {
                // Rethrow with original maxWaitMs to prevent logging exception with remainingWaitMs
                final String errorMessage = getErrorMessage(partitionsCount, topic, partition, maxWaitMs);
                if (metadata.getError(topic) != null) {


Would it be better to refactor it like this:

Errors error = metadata.getError(topic); if (error != null) { cause = error.exception(); } else if (ex.getCause() != null) { cause = ex.getCause(); } else { cause = new KafkaException(METADATA_TIMEOUT_MSG); } throw new TimeoutException(errorMessage, cause);

Also, since ex.getCause() != null can never be true based on the current awaitUpdate implementation, do we need to check for it?

Yunyung · 2025-08-03T19:05:03Z

...ts/src/main/java/org/apache/kafka/clients/producer/internals/TransactionalRequestResult.java


    public void await() {
-        this.await(Long.MAX_VALUE, TimeUnit.MILLISECONDS);
+        this.await(Long.MAX_VALUE, TimeUnit.MILLISECONDS, () -> new KafkaException("Unknown reason."));


Suggested change

this.await(Long.MAX_VALUE, TimeUnit.MILLISECONDS, () -> new KafkaException("Unknown reason."));

this.await(Long.MAX_VALUE, TimeUnit.MILLISECONDS);

@Yunyung thanks for your suggestion. 🙇‍♂️

However, I would like to keep my current code for this review.
The purpose of KAFKA-17019 is to ensure that any TimeoutException thrown by ProducerClient always includes a root cause.

To elaborate, the root cause may sometimes appear meaningless, such as Unknown Error.
However, by doing so, every call site that catches a TimeoutException can use the root cause without having to check whether it is null or not.

What do you think?

Hi, these two lines are exactly the same for your current change, right?
this.await(Long.MAX_VALUE, TimeUnit.MILLISECONDS); (This will call public void await(long timeout, TimeUnit unit))
this.await(Long.MAX_VALUE, TimeUnit.MILLISECONDS, () -> new KafkaException("Unknown reason."));

Oh, My Bad...!!!
Thanks for pointing it out 🙇‍♂️

chickenchickenlove · 2025-08-14T15:25:05Z

@AndrewJSchofield @Yunyung
I made several commit to address review!
When you have time, please take another look! 🙇‍♂️

chickenchickenlove · 2025-08-20T13:33:15Z

@AndrewJSchofield @chia7712 @Yunyung @frankvicky
Gently ping!
When you have time, please take another look 🙇‍♂️

chia7712 · 2025-08-23T18:16:10Z

@chickenchickenlove please rebase code to include CI changes.

chickenchickenlove · 2025-08-24T03:51:25Z

@chia7712 thanks for your comments!
I rebased to current trunk commit.
When you have time, please take another look.

chickenchickenlove · 2025-11-01T04:18:11Z

@chia7712

Also, I have something to tell you.
Currently, ProducerMetadata#awaitUpdate(...) refers to time.watiObject(...)

time is SystemTime and it is public API and throws TimeoutException without root cause
So, In this PR, I couldn't handle it.

It seems that would only be possible if I propose a KIP to add a new API to the SystemTime class:

public void waitObject(Object obj, Supplier<Boolean> condition, long deadlineMs, Supplier<KafkaException> expectedCause) { ... }

and that KIP gets approved.

What do you think?

chia7712 · 2025-11-01T18:41:45Z

public void waitObject(Object obj, Supplier condition, long deadlineMs, Supplier expectedCause) { ... }

Are there situations where using a custom exception is necessary for clearer error reporting?

chia7712

@chickenchickenlove thanks for updates. I have left a couple of comments

chia7712 · 2025-11-01T18:54:43Z

clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java


+    private static final String INIT_TXN_TIMEOUT_MSG =
+            "InitTransactions timed out – could not discover the transaction coordinator or "
+            + "receive the InitProducerId response within max.block.ms (broker unavailable, "


ditto - could we avoid those specific root cause?

I have revised it to make the content more general. 👍

chia7712 · 2025-11-01T18:54:53Z

clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java

+    private static final String SEND_OFFSETS_TIMEOUT_MSG =
+            "SendOffsetsToTransaction timed out – unable to reach the consumer-group or "
+            + "transaction coordinator or to receive the TxnOffsetCommit/AddOffsetsToTxn response "
+            + "within max.block.ms (coordinator unavailable, rebalance in progress, network lag, or ACL denial).";


clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java

chickenchickenlove · 2025-11-02T02:47:20Z

@chia7712 , thanks for your comments.

Are there situations where using a custom exception is necessary for clearer error reporting?

    // https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java#L1224
    private ClusterAndWaitTime waitOnMetadata(String topic, Integer partition, long nowMs, long maxWaitMs) throws InterruptedException {
           ...
            try {
                metadata.awaitUpdate(version, remainingWaitMs); // <----
            } 
           ...

Here, a TimeoutException is thrown by SystemTime.
However, when a TimeoutException occurs, it’s not possible to know the specific cause of the error.
Therefore, by providing an expected error through a Supplier, we can obtain more contextual information about the likely cause when a TimeoutException is thrown at runtime.

chickenchickenlove · 2025-11-02T02:48:15Z

@chia7712
Thanks for your reviews!
I made a new commit based on your comments,
When you have time, please take another look 🙇‍♂️

chia7712 · 2025-11-06T16:29:00Z

Here, a TimeoutException is thrown by SystemTime.

the case waitOnMetadata is already handled by this PR, right?

chickenchickenlove · 2025-11-07T01:41:16Z

@chia7712 Ah, Sorry. You are right.
This PR handles it as well.
Sorry for making you confused.

chickenchickenlove · 2025-11-12T00:52:48Z

@chia7712 Hi!
Sorry to bother you continuously.
If there is something to do to make this PR merged, Please let me know!
I will dig into it more!
Thanks always 🙇‍♂️

chia7712 · 2025-11-12T10:26:37Z

clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java

                    throw new TimeoutException(errorMessage, metadata.getError(topic).exception());
                }
-                throw new TimeoutException(errorMessage);
+                if (metadata.getError(topic) != null) {


I left a comment on the origin PR https://github.com/apache/kafka/pull/16344/files#r2517753553. Understanding the origin design point would be very useful

@chia7712 thanks for your comments.
I will stay tuned!
If there is something to do, Please let me know, I'm willing to do so.
Thanks always! 🙇‍♂️

Could you please revert this change? The non-retriable error should not be included within the retriable TimeoutException

@chia7712 thanks for digging into it!
I reverted!
I understood it this way and reverted the change.
TimeoutException is a type of RetryableException, but in this code, we only want to include it as the cause when a more explicit RetryableException is present.

After reading the discussion at #16344 (comment), I note that adding KafkaException creates a strange scenario where a retriable exception has a non-retriable error as its root cause. This could confuse users when handling the exception. Did we discuss simply enriching the exception message directly instead?

@chia7712
Gently ping and sorry to bother you 😢
Could you share your thoughts with me?
Thanks a lot 🙇‍♂️

I have to say, my concern remains the inconsistent exception hierarchy. This inconsistency could lead users to mistakenly catch a non-retryable exception.

ping @mjsax WDYT?

Hi @chia7712 !
I updated the PR based on your comments (reverted the KafkaException change and improved the log messages).
When you have time, please take another look.
Thank you again for your time 🙇‍♂️

@chickenchickenlove thanks for your updates. I think current version is less controversial so we can accept it first. If there are more discussion later, we can modify the error structure (maybe it needs a KIP)

Thank you for taking the time to review this PR. 🙇‍♂️
Thanks to you, I learned a lot, and I’ll make sure to take these points into consideration when writing my next PR.

chickenchickenlove · 2025-11-12T23:53:55Z

I rebased on f685d57 (latest commit).
Resolve trivial comment conflict in KafkaProducer.java.

chickenchickenlove · 2025-11-16T13:32:14Z

@chia7712 Sorry to frequently mention you 😭
If there is something to do, Please let me know 🙇‍♂️

chia7712 · 2025-12-13T16:58:23Z

clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java

    public static final String NETWORK_THREAD_PREFIX = "kafka-producer-network-thread";
    public static final String PRODUCER_METRIC_GROUP_NAME = "producer-metrics";

+    private static final String INIT_TXN_TIMEOUT_MSG = "InitTransactions timed out — " +


Let's stick to the ASCII hyphen - and avoid using the longer dashes – or —. I will prepare a patch for this change

Thanks for comments.
I'll make sure to keep this in mind for the next PR. Thanks in advance for your patch as well. 🙇‍♂️

Don't worry. a small issue won't bring down kafka:smile

open #21148

…he#20159) ### Changes - Add new Exception class `PotentialCauseException`. - All `org.apache.kafka.common.errors.TimeoutException` in `KafkaProducer` has `PotentialCauseException` as root cause if it cannot catch any exception. ### Describe `TimeoutException` can be thrown for various reasons. However, it is often difficult to identify the root cause, Because there are so many potential factors that can lead to a `TimeoutException`. For example: 1. The `ProducerClient` might be busy, so it may not be able to send the request in time. As a result, some batches may expire, leading to a `TimeoutException`. 2. The `broker` might be unavailable due to network issues or internal failures. 3. A request may be in flight, and although the broker successfully handles and responds to it, the response might arrive slightly late. As shown above, there are many possible causes. In some cases, no `exception` is caught in the `catch` block, and a `TimeoutException` is thrown simply by comparing the `elapsed time`. However, the developer using `TimeoutException` in `KafkaProducer` likely already knows which specific reasons could cause it in that context. Therefore, I think it would be helpful to include a `PotentialCauseException` that reflects the likely reason, based on the developer’s knowledge. Reviewers: TengYao Chi <kitingiao@gmail.com>, Yung <yungyung7654321@gmail.com>, Andrew Schofield <aschofield@confluent.io>, Chia-Ping Tsai <chia7712@gmail.com>

github-actions bot added triage PRs from the community producer clients small Small PRs labels Jul 12, 2025

frankvicky added the ci-approved label Jul 12, 2025

frankvicky reviewed Jul 12, 2025

View reviewed changes

chickenchickenlove force-pushed the KAFKA-17019 branch from a77073f to abc86a6 Compare July 12, 2025 09:14

chickenchickenlove requested a review from frankvicky July 12, 2025 09:17

github-actions bot removed the triage PRs from the community label Jul 13, 2025

AndrewJSchofield added the kip Requires or implements a KIP label Jul 14, 2025

chia7712 reviewed Jul 14, 2025

View reviewed changes

AndrewJSchofield removed the kip Requires or implements a KIP label Jul 16, 2025

chickenchickenlove force-pushed the KAFKA-17019 branch from 54df407 to 66215de Compare July 19, 2025 09:44

chickenchickenlove requested review from AndrewJSchofield and chia7712 July 19, 2025 13:39

AndrewJSchofield requested changes Jul 31, 2025

View reviewed changes

Yunyung reviewed Aug 3, 2025

View reviewed changes

github-actions bot removed the small Small PRs label Aug 14, 2025

chickenchickenlove requested review from AndrewJSchofield and Yunyung August 14, 2025 15:24

chickenchickenlove force-pushed the KAFKA-17019 branch from b11a4f2 to ddb777c Compare August 24, 2025 01:25

chia7712 reviewed Nov 1, 2025

View reviewed changes

chickenchickenlove requested a review from chia7712 November 2, 2025 03:42

chia7712 approved these changes Nov 12, 2025

View reviewed changes

chia7712 reviewed Nov 12, 2025

View reviewed changes

chickenchickenlove added 11 commits November 13, 2025 08:51

KAFKA-17019: Producer TimeoutException should include root cause

3198f60

Addressing PR review.

5b328c4

Addressing PR review.

0cde758

Addressing Review.

7a52797

Addressing Review.

33fe23c

Addressing review.

a6291d5

Addressing Review.

62745a2

Revert SystemTime in common interface and fix wrong test codes.

257a518

Fix wrong usecases in test codes.

56264c7

Addressing Review.

cc57077

Addressing Review.

aa7e6b9

chickenchickenlove force-pushed the KAFKA-17019 branch from 1b9dba0 to aa7e6b9 Compare November 12, 2025 23:52

chickenchickenlove added 2 commits November 30, 2025 19:54

Revert aee7e6b9..3198f60

8839e92

Addressing review.

36fc4cf

chia7712 merged commit 917d695 into apache:trunk Dec 3, 2025
24 checks passed

chia7712 reviewed Dec 13, 2025

View reviewed changes

	accumulator.resetNextBatchExpiryTime();
	List<ProducerBatch> expiredInflightBatches = getExpiredInflightBatches(now);
	List<ProducerBatch> expiredBatches = this.accumulator.expiredBatches(now);
	expiredBatches.addAll(expiredInflightBatches);

	// Reset the producer id if an expired batch has previously been sent to the broker. Also update the metrics
	// for expired batches. see the documentation of @TransactionState.resetIdempotentProducerId to understand why
	// we need to reset the producer id here.
	if (!expiredBatches.isEmpty())
	log.trace("Expired {} batches in accumulator", expiredBatches.size());
	for (ProducerBatch expiredBatch : expiredBatches) {
	String errorMessage = "Expiring " + expiredBatch.recordCount + " record(s) for " + expiredBatch.topicPartition
	+ ":" + (now - expiredBatch.createdMs) + " ms has passed since batch creation";
	failBatch(expiredBatch, new TimeoutException(errorMessage), false);

	this.await(Long.MAX_VALUE, TimeUnit.MILLISECONDS, () -> new KafkaException("Unknown reason."));
	this.await(Long.MAX_VALUE, TimeUnit.MILLISECONDS);

KAFKA-17019: Producer TimeoutException should include root cause #20159

KAFKA-17019: Producer TimeoutException should include root cause #20159

Conversation

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

Uh oh!

Changes

Describe

Uh oh!

frankvicky left a comment

Choose a reason for hiding this comment

Uh oh!

frankvicky Jul 12, 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!

AndrewJSchofield commented Jul 14, 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!

chickenchickenlove Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

It’s hard to pinpoint the root cause in every situation where a TimeoutException occurs

Idea + Pros and Cons

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chickenchickenlove Jul 15, 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!

chickenchickenlove commented Jul 14, 2025

Uh oh!

AndrewJSchofield commented Jul 15, 2025

Uh oh!

chickenchickenlove commented Jul 19, 2025

Uh oh!

chickenchickenlove commented Jul 27, 2025

Uh oh!

AndrewJSchofield left a comment

Choose a reason for hiding this comment

Uh oh!

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

Yunyung Aug 11, 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!

chickenchickenlove commented Aug 14, 2025

Uh oh!

chickenchickenlove commented Aug 20, 2025

Uh oh!

chia7712 commented Aug 23, 2025

Uh oh!

chickenchickenlove commented Aug 24, 2025

Uh oh!

chickenchickenlove commented Nov 1, 2025

Uh oh!

chia7712 commented Nov 1, 2025

Uh oh!

chia7712 left a comment

Choose a reason for hiding this comment

chickenchickenlove commented Jul 12, 2025 •

edited by github-actions bot

Loading

frankvicky Jul 12, 2025 •

edited

Loading

chickenchickenlove Jul 14, 2025 •

edited

Loading

It’s hard to pinpoint the root cause in every situation where a `TimeoutException` occurs

chickenchickenlove Jul 15, 2025 •

edited

Loading

Yunyung Aug 11, 2025 •

edited

Loading