Offline request queue not synching when app force closed

[igor-kualia]

Steps to reproduce:

1. Turn on internet
2. Upsert row
3. Turn off internet
4. Delete row
5. Close app (not backgrounded)
6. Turn on internet
7. Open app and wait however long, or perform other actions
8. Check Supabase and notice the locally-deleted row is still on remote.

Note:
This is not a problem if you replace step 5 above with moving the app to the background. Re-opening the app will synch the delete correctly.
It also is not a problem if you replace step 4 above with Update row. Nevermind. Does this for upserts as well.

It seems the offline queue is losing the requests in at least the scenario where the app is force closed before connection is restored. There may be other scenarios, but this one I have confirmed.

Any ideas?

[tshedor]

@igor-kualia are you re-initializing your queue on start up? It sounds like maybe the queue isn't getting reinvoked on a code path that you have for app start

[nyejon]

I seem to have the same issue.

1. Switch off internet
2. Create a new object offline
3. Close app
4. Turn on internet
5. Open app

When I check the Supabase logs, there are no post requests created and the created object never syncs.

[nyejon]

I'm not sure if this is related, but sometimes I get 401 errors on supabase when brick continuously tries to upload the same object. It looks like the token might not be updated on the queue after the supabase token has been refreshed?

[tshedor]

@nyejon @igor-kualia by default, 401 responses are not retried. However, the helper for configuring the Supabase client includes 401s. Can you both see what sort of responses you're getting when the app restarts the queue, and can you confirm that you are re-initializing the queue?

[igor-kualia]

I can confirm that this is working now. However, it occasionally takes a bit for the queue to begin processing.

When I originally created this ticket, the queue took about 30 seconds to a minute to begin firing. During my testing, I never waited around that long to see if it would begin, so that's why I created this issue. If I had just waited a bit longer I would have seen it work.

One time I just decided to wait longer to see if it would eventually fire, and it did. I clocked it around that 30second-1 minute mark. I'm not sure if there is anything to investigate there.

If @nyejon has a problem, I would suggest printing out your queue as they're firing. One issue I had that may have led me down this path was a stubborn 500 (I think) error call got stuck in the queue on a loop and attempted 800+ times before I realized it. I think this failing request blocked the rest of the requests from firing. That's unrelated to this issue though, just something to check.

@nyejon, if you wait around for 3+ minutes and your queue still doesn't start, let us know. It might have been a difference between simulator vs physical device. But that's just a guess.