-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Introduce ExecutionRejectedException.TelemetrySource
property
#2352
Conversation
ExectuionRejectedException.TelemetrySource
propertyExecutionRejectedException.TelemetrySource
property
/// Updates the <see cref="ExecutionRejectedException.TelemetrySource"/> property of the exception. | ||
/// </summary> | ||
/// <param name="exception">The exception to update.</param> | ||
public void UpdateTelemetrySource(ExecutionRejectedException exception) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can even hide this initially with [EditorBrowsable(EditorBrowsableState.Never)]
?
{ | ||
Exception exception => new BrokenCircuitException(BrokenCircuitException.DefaultMessage, retryAfter, exception), | ||
_ => new BrokenCircuitException(BrokenCircuitException.DefaultMessage, retryAfter) | ||
}; | ||
|
||
_telemetry.UpdateTelemetrySource(ex); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO this method call is super easy to forget. Also if someone wants to construct any of the Polly exception (for whatever reason) then she has to be aware of this feature and has to use it.
If we go with this approach to decorate all Polly exceptions (that derives from the So, if we extend the Polly exceptions with |
How about we treat the If someone complains that they want to attach this property when constructing the exceptions, we can do the follow-up where we expose a new set of constructors for all relevant exceptions? Alternatively, we can do it now. One thing I feel quite convinced about is to expose the full |
I'm okay with this approach. Do you want to finish this PR or shall I incorporate the idea into my PR? |
If you are OK with incorporating this, please continue in your PR :) @martincostello Are you fine with above approach? |
I'm not against the idea of the pub-ternal API. I think if we go down that route it's better to do the minimal amount and do more later if asked for, otherwise it's going to end up being quite a big change in terms of additional API surface area. |
this proposal really only adds one new pub API - i.e. @peter-csala please go ahead! |
Unfortunately no :( The I try to extend only the Polly.Core and Polly.RateLimiting exceptions. |
I would say it's ok, it's nullable anyway so on V7 this property will never be filled. |
Duplicate of #2346 |
Just an experiment on how we can uniformly introduce telemetry source to all our exceptions.
The idea is that rather to introduce many new overloads to exception constructors, we can update this property centrally. It's niche enough< so my thinking is we don't need to expose this parameter in exception constructor. If someone complains, we can do it later anyway.
Contributes to #2346 and #2345
cc @peter-csala, @martincostello
Your thoughts?
Pull Request
The issue or feature being addressed
Details on the issue fix or feature implementation
Confirm the following