excluding certain requests from offline queue?

[jamesdixon]

Hi, @frank06!

Working on the "new" Scout app in my "free" time and came across something that I wanted to get your take on.

With FD's current offline setup, any operation that results in an OfflineException is stored in the queue to retry. However, there are cases when you would not want every single operation retried. Here's an example from the Scout app:

1. You're on the schedule screen, which lists all of your appointments.
2. You go offline.
3. You tap on a specific appointment, which triggers a GET request to fetch the details of the appointment. This request fails because you're offline, but the user still sees the appointment details from the local database.
4. You tap on the "check in" button, which triggers a POST request to an endpoint. Because I want the user to be able to check in and out from an appointment while offline, I catch the OfflineException and update the status of the appointment locally to in progress.
5. Now that the appointment is in progress, I can proceed to "check out." Tapping the check out button triggers a POST request to an endpoint. Since we're offline, I get an OfflineException and update the status of the appointment locally to completed.

This all works great except that when you come back online, the result of the GET request marks the appointment as scheduled again. This ends up resolving itself because of the other POST requests that follow but makes the user experience a bit wonky.

All that said, I'm curious if having the ability to exclude certain types of requests from being retried? For example, since any requests that modify state are done by POST/PATCH in the Scout app, I don't have a current need to retry GET requests. I'm currently filtering this out in the code that retries offline requests, but it'd probably be ideal to skip those entirely so they never make it to the queue.

I do see isNetworkError but overriding that to always return false appears to skip offline retries for the entire model.

Lemme know what ya think or if this is something that feels to specific to my use case.

Cheers

[frank06]

Hey @jamesdixon ! Yeah, I would've said the logical place to implement this would be isNetworkError. Can't you conditionally return false there or there is not enough request information at that point?

The other option is to override sendRequest just like _RemoteAdapterOffline does, specifically in the onError handler (line 60).

Filtering out during the retry logic seems to be the most straightforward way, have you encountered limitations doing that?

[frank06]

@jamesdixon Latest versions of FD only treat writes as offline operations, so in your case there would be no need to exclude GET requests