Hitting follow then back quickly can result in follow silently failing, esp under high server load

[mcclure]

On 2022-Oct-31 mastodon.social was under very heavy load due to the Twitter buyout, exposing some Tusky misbehaviors when the server is responding slowly.

Repro steps:

• Tap a user avatar to open their user page
• Tap "Follow". Observe that "Follow" has changed to "Unfollow".
• Immediately tap the Android system "Back" button to return to the feed.
• Wait a few seconds then open the user page again to confirm the follow worked.

Expected behavior:
The user is followed.

Observed behavior (if the server is under heavy load):
The user is not followed, even after waiting. According to @connyduck on Matrix, the "Follow" button changes to "Unfollow" optimistically, but the follow request is abandoned when the user page is dismissed.

Analysis:

I think "Follow" changing to "Unfollow" is good behavior, but mastodon should do a better job of catching an unusual case where the follow fails or takes so long the user navigates away (hits "back", or even quits Tusky)

The biggest problem here IMO is that the user is not notified, IE, they think they followed and won't notice they didn't unless they think to double check.

Connie's suggested fix: "turn the button into a spinner while the request is in flight", the user would then one assumes wait for it to complete spinning before navigating away
My suggested fix: Eagerly switch to "unfollow", but if the user starts navigating up block them with a modal dialog until the follow request completes (Connie said this sounds harder than the spinner, and it might not catch the case where Tusky itself is dismissed).

---

• Tusky Version: 19.0
• Android Version: 12
• Android Device: Sony XPeria 5 III
• Mastodon instance (if applicable): mastodon.social

[connyduck]

I bet Pete hit that bug https://mastodon.social/@PeteWM1@mas.to/109406278480222481

[nikclayton]

The user shouldn't be blocked by a modal dialog. I've fixed some of this for notifications in https://github.com/tuskyapp/Tusky/pull/3159, as a model for how to rewrite the other fragments to handle it.

If an error occurs during a network operation the user is shown the error, with an opportunity to retry it. If the UI opportunistically showed the operation as succeeding (e.g., try and bookmark a status in airplane mode with the previous code, it will show the bookmark as succeeding) the UI is reset to show the operation did not succeed.

It's only a partial solution, because the state is lost when the user navigates away.

The current problem is because the UI can only show the user one of two states.

• This is the current state of the world
• This is your desired state of the world

Right now, in most places, the default is "This is your desired state of the world". Opportunistically showing "Follow" as succeeding, for example.

This leads to user confusion ("The UI tells me I bookmarked this post, why is it not showing up in my list of bookmarks?", etc).

Showing "This is the current state of the world" also has problems. Click "bookmark", nothing seems to happen, click it again, etc.

Part of the fix for this is for long running operations (roughly, anything that doesn't complete in 250ms) is to show a progress spinner, as @connyduck suggests. This communicates that something is happening to the user.

That works for the fragment/activity that the user is in, but that information is lost when they navigate away, and the network operation is lost when the coroutine is cancelled.

I haven't sketched out a complete solution for this yet, but at the moment it looks something like:

When the user interacts with an element (e.g., bookmark):

• Send the request via a new MastodonRepository object (probably including a WeakReference to this, and the class name, see later)
• Wait up to 250ms collecting a positive response, update the UI if received
• > 250ms and no positive response? Set the UI element to include a progress spinner
• Continue collecting a positive response, update the UI if received

When the MastodonRepository receives a request:

• Store the request in a queue of pending requests (store the request, and the WeakReference)
• Execute the request when possible (probably by handing it off to a long-lived service to do the execution)
• Success? Delete the request, emit a "Success" response
• Failure? Put the request back in the queue, with metadata indicating when to retry it
• Don't retry forever, If it retried too many times, or the API call 4xx'd, emit an error

When a fragment/activity wants to display something in the UI (e.g., a status):

• Fetch the necessary data from the API as currently happens
• In addition, collect the queue of pending requests from the MastodonRepository
• Update the UI with data from the API, but also check and see if any of the UI elements have queued requests (e.g., "Does status with ID X have a pending bookmark request?" or "Does account with ID X have a pending Follow request?")
  • If it does, set the relevant bit of the UI to a spinner, to clearly communicate that there's something going on

Other stuff a fragment/activity does:

• Collect successes and errors from the MastodonRepository
• Each success/error should include the WeakReference that was passed in, and the class
• This allows this activity/fragment to know (a) is this a response to something I did, or (b) is this a response to something a previous instance of my class did, or (c) is this a response to something another fragment/activity did?
• The answer to that question determines what the fragment/activity does. If it's (a) or (b) they probably update the UI or show a more detailed error. If it's (c) and successful there's no need to update the UI, but if it's (c) and a permanent error there's probably a need to notify the user.

That last one covers the situation where:

• The user clicks "Follow" on a profile
• The user navigates somewhere else (e.g., to a timeline)
• The follow request repeatedly fails / hits a retry limit
• The user should be told that the follow request failed. With enough info to know why, and whether or not to retry (and retrying might not be possible -- maybe they've been blocked by the person they're trying to follow).

This covers all the bases:

• The UI always shows the correct current state of the world (where that state includes "a request is currently in flight")
• Users can navigate around the app without risking requests being lost, and without being blocked by a modal dialog
• In-progress requests are persisted, so they're not lost if the app crashes or is killed by the OS

[mcclure]

Now that mastodon.social has generally fixed its scaling issues we should think about how to test a fix for this…