Ability to ignore exception types when counting breaker errors #37
Conversation
| { | ||
| CircuitBreaker.Metrics.MarkCommandFailure(); | ||
| if (CommandContext.IsExceptionIgnored(e.GetType())) |
There was a problem hiding this comment.
Could e be wrapping another exception let us the implements is awaiting on an async call for example, and that throws an exception, for now do we just get e's type? I don't see an immediate need but wanted to plant a seed, if it is worth planting
There was a problem hiding this comment.
Yeah, possibly. I'm not sure how expensive it'll be to add an IsAssignableFrom() or equivalent call into here, though. I'll look into it - good call.
There was a problem hiding this comment.
Having thought about this a bit more, I think I like the non-inheritance checking way. It's easy to opt into more types if you want parents/children to also be ignored, but if we use IsAssignableFrom() and assume the whole hierarchy, it doesn't leave the option to opt out of any children that you don't want ignored.
Ability to ignore exception types when counting breaker errors
Particularly with
[Command], there can be times where an exception (e.g. an input validation error) gets thrown fromExecuteAsync(), but we shouldn't increment the breaker error count because there's actually nothing wrong with the service.Add the ability to register a list of ignored exception types, which will be counted as success instead of failure.
A future consideration would be to add a third metric (alongside success and failure) to track these independently - I don't see the need for that just yet.