New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retry failed "mark as read" requests #4559
Comments
I believe I've also got a |
Actually, thinking about this again I think it's not. (Though it'd still be good to do.) We can go ahead and do #3549 without blocking on this. I explained why at an old comment #3549 (comment) :
|
Started a conversation on CZO #mobile-team > non-redux storage? about using SQLite to persist this data. |
(Update 2022-11: Since #4620, we do retry these requests. But only (a) the next time the user scrolls past some other unread messages, which may happen arbitrarily far in the future or never happen, and (b) while the app remains running -- we don't persist to disk the user's desire to mark the messages as read. So the main content of this issue still applies.)
Currently, if a API request to mark messages as read fails, we never retry it. Instead, we should save a list of messages we have tried to mark as read (this should be persisted to disk, ideally, although maybe just putting it in the Redux state is a good enough start), and retry them periodically (probably using exponential backoff, maybe with some jitter?)
I think we should probably do this for every
messagesFlags
call, not just read state: thing like starring messages deserve to not be lost as well.One thing I'm not sure about is how to deal with stateful logic in the
src/api/
code — I don't know what dependencies we're OK with that code having (can it save stuff in Redux?). I think it would be good to aim to have fairly generic code for retrying any sort of API request, which we can at first just have apply tomessagesFlags
, but can add to other methods later, if we want.It's also worth thinking about how the
auth
will get passed around when we do this — we want whatever is clearing out the retry queue to have the most recentauth
rather than the one that the message was first sent with, most likely. We should also make sure that the code doesn't accidentally send messages to the wrong realm.Related: #4558, #4526, #3549, #3423, #500
The text was updated successfully, but these errors were encountered: