Provide an option to turn off caching of exceptions

[bbakerman]

I am using GraphQL Java 8.0, which uses Dataloader 2.0.2 . I have experienced it lot of times that dataloader caches the exceptions returned from the batchload function. After reading the code I came across this piece in Dataloader.java .

return batchLoad
                .toCompletableFuture()
                .thenApply(values -> {
                    assertState(keys.size() == values.size(), "The size of the promised values MUST be the same size as the key list");

                    for (int idx = 0; idx < queuedFutures.size(); idx++) {
                        Object value = values.get(idx);
                        CompletableFuture<V> future = queuedFutures.get(idx);
                        if (value instanceof Throwable) {
                            stats.incrementLoadErrorCount();
                            future.completeExceptionally((Throwable) value);
                            // we don't clear the cached view of this entry to avoid
                            // frequently loading the same error
                        } else if (value instanceof Try) {

It says that dataloader is caching the error response from batchloader. I want to know why this type of design was added ?
I have a long duration cache for some fields and if their datasource fails , it will return error responses to my graphql server. If it recovers after small time then I would still return the stale responses (errors) to my clients because of this feature in dataloader.
Also if there is an issue with frequently loading the same error, then the users can add some code like circuit breakers etc to stop calling the backend.
I am not sure if this is fixed for the newer versions of dataloader.
If there is a way to not store the exceptions can you please inform me.

I think at the time it was decided that if a value was poisoned then dont keep asking for it. This works well for short lived per request caches
However ads you say if you have long lived caches, then this works against you.
Can you please raise an issue on data loader project for this.
In the meantime you can work around it by

1. clearing the cache for exceptionally values
2. implementing a custom cache function that simply ignores exceptions
   See org.dataloader.DataLoaderOptions#setCacheMap

[bbakerman]

This is done