[FEATURE] FailSafe Customize Exception Handling

[cmeyertons]

This is a fantastic library, and I sincerely appreciate all the work that has gone into this.

Problem

The fail-safe functionality is great, however there are certain scenarios where we want the fail-safe to trigger for some exceptions (but not all).

It's very common for ApiClients to throw exceptions when the status code is not successful, however we don't want the fail-safe to trigger for these kinds of known, bad requests.

An example of this behavior would involve only fail-safing on API responses with status codes >= 500, and letting 400-499 exceptions bubble up normally (400s, 404s, 401s, 403s, etc)

Solution

I would like the ability to configure the FailSafe mechanism with an optional Exception Filter.

Something like:

public class FusionCacheEntryOptions
{
     public Func<Exception, bool>? FailSafeExceptionFilter { get; set; }
}

Alternatives

Alternatively, we have to jump through hoops to adaptively turn off fail safing for specific error codes and cannot easily configure this behavior across numerous cache invocations (have to implement wrapper code, etc)

[jodydonetti]

Hi @cmeyertons I'm glad you're liking FusionCache 🙂

Instead of an exception filter I'm thinking about something like adaptive caching, but I have to doublecheck if fail-safe can be changed (the docs says no but maybe it can, not sure 100%).

Let me get back to you.

[jodydonetti]

Ahah, and there it is 😅 I should've read all the pending issues before start answering...

UPDATE: I'm taking a look at the PR right now: it seems fine, but I have to also check combos like fail-safe + other stuff (eg: soft/hard timeouts and so on).

Will get back to you, meanwhile thanks!

[cmeyertons]

Haha sorry, i forgot to update this issue 😅

Happy to help! I still think this issue is valid (even with adaptive fail-safe PR) because it allows me to declare the exception handling in one place.

With adaptive caching, I have to handle this behavior on each factory function (implement some wrapping code etc etc), This is still do-able but somebody might forget to do it eventually.

It would be great if I could define a default, consistent exception handling behavior and know the exception handling behavior will be consistent across the application.

I was using adaptive caching as a workaround for this issue, and then ran into that problem as well during testing 😅

[cmeyertons]

I'm happy to contribute this as well, just lmk if the approach is reasonable.

[jodydonetti]

Will think about the exception filter a little bit more, including all the implications, edge cases, etc.

[jodydonetti]

Hi all, v1.3.0 is out 🥳

[cmeyertons]

Can we re-open? Not fixed via 1.3 unless you added the filtering mechanism