-
Notifications
You must be signed in to change notification settings - Fork 845
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExecutionInterceptor access to request attempt exceptions #929
Comments
I don't believe we have a hook for each individual exception. This sounds like a good idea though. Quick question, for the final exception would you expect it to call this per exception hook in addition to the onExecutionFailure method? |
I think it would yes. Maybe the exception would state whether the request will be retried, so that we could detect the last request if needed. I don't think it matters to our use case though so just having a hook for the individual http request and exception is enough |
…01a4c383 Pull request: release <- staging/0c7c8a02-8615-4fc9-99a4-4cf601a4c383
is this still not done? I was getting the exception details with retryCondition and adding them to the executionattributes but this has just been marked deprecated so are we back to no way to get the exceptions? |
Maybe this is just a documentation change that is needed but reading through the
ExecutionInterceptor
comments and traversing through the code I don't see a way to get access to the intermediate exceptions that get retried.Expected Behavior
ExecutionInterceptor
should have a hook likeonRequestFailure
that would give access to the exception for a specific HTTP request. This would provide the ability to see throttles and other types of events at the request level when it may resolve during the retries.Current Behavior
The current behavior as I understand it is to add some internal state to the retry handler but to only emit that once the retries have been exhausted.
Possible Solution
Add a new Stage for
RequestFailure
that theRetryableStage
can delegate to for these hooksContext
When we instrumented the V1 SDK we had the ability to retrieve the intermediate exceptions. With V2 that is not possible at the moment. See openzipkin/zipkin-aws#116 for the corresponding issue on our end.
The text was updated successfully, but these errors were encountered: