RTK-Query - trigger refetch without retries

[andreiciceu]

Hello,

Firstly, nice work on this helpful library. Makes working with redux & API requests much simpler & streamlined.

I'm trying to use RTK-Query / refetch in a not-so-standard way (trigger a refetch manually, but do not retry on fail), but I'm probably not the only one with this use case (as pull-to-refresh or re-sync buttons are pretty common). Due to how queries are constructed, I think this is now a limitation of the RTK Query API. Or is there another way to go around it?

Whole story

A user can trigger refetch for a query. In case of error for that refetch, the user is notified. In combination with the retry mechanism (if for example the api is down), the refetch hangs with no success or error for a long time (until maxRetries is reached) and only after fails.

Ideally in this case, if the first request fails, we need some kind of mechanism to opt out of retrying (but only for this particular user-initiated refetch). Maybe something like the feature proposed in #1354

Many thanks!

[markerikson]

Very belated response here, but I'm not quite sure what's being asked for. Can you give more examples? What exactly "hangs"?

[andreiciceu]

The refetch action only resolves after maxRetries requests have been tried; in the case that all requests timeout, the Promise "hangs" in an unresolved state; this could potentially be a long period of time, in which there's no way to know the first one failed. And in some cases, there's only one try intended (e.g. pull to refresh)

What was needed, when the issue was opened (is this still needed? @cristicsk @riurisniti), was a method of manually initiating a refetch that (in the case of failure, e.g. timeout) it won't retry the request (acting as maxRetries is 0, but only for this particular instance).

Simple example:

1. maxRetries is set to 5
2. User pulls down the view, with the intent to refresh the data
3. An action is dispatched to rtk, with maxRetries: 0, so it rejects immediately after the first request fails, and no subsequent retries are made
4. The user is informed in some way about the failure

[riurisniti]

@andreiciceu thanks for keeping up with this thread. Not sure if we need this right now tbh, we just make sure that those queries that can be user triggered are constructed with maxRetries: 0

To clarify further on what was needed:

• On custom base query creation for a createApi instance, you can have the query wrapped by the retry wrapper
• retry allows for customization via its RetryOptions with maxRetries, additionally all api endpoints can be further customized when calling build.query via extraOptions with maxRetries
• as far as I looked into it, we cannot change this after the initialization of the createApi instance (I might be wrong and missed something)
• this would be usefull in cases where we might want to use a dispatch call with endpoint.initiate and pass to it somehow new extraOptions where maxRetries is 0

cc: @markerikson