chore: demonstrate how to handle an inflight request timeout exception#2441
Conversation
e171ae7 to
5b4d15c
Compare
| } else if (throwable instanceof StreamWriterClosedException) { | ||
| StreamWriterClosedException swce = (StreamWriterClosedException) throwable; | ||
| Status status = swce.getStatus(); | ||
| if (status.getCode() == Code.ABORTED) { |
There was a problem hiding this comment.
Why we only retry on aborted error?
There was a problem hiding this comment.
The StreamWriterClosedException can be returned when:
(a) user has already called close() on the ConnectionWorker. This has code FAILED_PRECONDITION set. In this case the client could retry, but must be using a different ConnectionWorker. In the sample code, we don't create a new JsonStreamWriter if user had already closed it. So if we did a retry on the same ConnectionWorker, it would cause an infinite loop. We would have to change the existing logic to support this.
(b) connection has a final status set on it, indicating an error occurred. This has code FAILED_PRECONDTION set. In this case the client should retry, but using a different ConnectionWorker. So this case would be ok to retry. However, we can't distinguish it from case (a).
(c) connection has been closed, but there was an inflight request. This has code FAILED_PRECONDTION set. In this case the client should retry, but using a different ConnectionWorker. So this case would be ok to retry. However, we can't distinguish it from case (a).
(d) connection has been closed and there was an error, and this is the second or later inflight request. This has code ABORTED set. In this case the client should retry, but using a different ConnectionWorker. So this case would be ok to retry. Currently this is the only case we handle.
There was a problem hiding this comment.
It sounds like we should distinguish the user closed case and not to retry there. Since we still hold the previous writer object, we could call writer.IsUserClosed and not to retry on that case only?
5b4d15c to
c96b986
Compare
The request with the specific timeout exception, along with any aborted requests, must simply be caught and retried on a new StreamWriter.
If using connection pooling, creation of the new StreamWriter will be handled automatically by the connection pool. Otherwise, we manually create and switch to using a new JsonStreamWriter before re-sending the request.