Closed ikhoon closed 4 months ago
Just to make sure, am I understanding correctly that this issue is still a problem even if RetryingClient
isn't in the decorator chain? (logs not completing could potentially pose a problem not restricted to retrying)
am I understanding correctly that this issue is still a problem even if RetryingClient isn't in the decorator chain? (logs not completing could potentially pose a problem not restricted to retrying)
Right. RequestLog
isn't completed regardless of RetryingClient
. So RequestLog
related operations such as LoggingClient
and MetricCollectingClient
do not work with the failed request before.
I try to complete RequestLog
if a response is returned by a decorator. I am not confident with the workaround though. I still need to come up with new ideas for the problem.
https://github.com/line/armeria/pull/5714/files#diff-f2eb8203256e0ecc52bed39c1f10697323d973d9f15c83096214794378fb197fR174-R178
Thanks! I was just curious while writing the weekly report. Will also take a look at the approach in the other PR later ๐
@ikhoon ๐ ๐ ๐
Motivation:
When
OAuth2Client
fails to acquire a granted access token, it directly returns a failed response. As the response is returned,RequestLog
is not completed.RetryingClient
waits for some properties ofRequestLog
to be completed. Therefore, the incompleteRequestLog
causesRetryingClient
to get stuck.This PR is a temporary workaround to fix the problem. The deadlock phenomenon will occur easily if a decorator returns a response directly. I created #5714 in which I will try to solve this problem ultimately.
Modifications:
getAccessToken()
completes exceptionally, completes the log and then returns a failed response.Result:
Fixed a bug where
RetryingClient
gets to deadlock whenOAuth2Client
fails to obtain an access token.