Race condition with async status operations i.e. Favorite, Boost

[danschwarz]

To reproduce- select any status and hit the [F]avorite or [B]oost keys multiple times rapidly. You will soon get an ApiError exception (status 422: "Validation failed: Status has already been taken")

This is how Mastodon 4.0.x responds to an attempt to Favorite a status that is already Favorited, or Boost (reblog) a status that is already Boosted (reblogged).

See this Mastodon issue referencing the problem. Closed in Mastodon 1.5 but that may be incorrect or this may be a regression. https://github.com/mastodon/mastodon/issues/3378

Possible fixes include one or more of these:

• Catch the exception and do something smart
• Block additional Favorite or Boost operations while a Favorite or Boost transaction is still executing asynchronously.
• Resync the favorite and boost flags before every update.

[ihabunek]

This is a weird issue, it does not always occur. I managed to get my test server in a state where I have two statuses, one which triggers the HTTP 422 and other which always returns HTTP 200 on multiple favourites.

λ toot favourite 109536251845873101
Validation failed: Status has already been taken

λ toot favourite 109397833714235268
✓ Status favourited

λ toot favourite 109397833714235268
✓ Status favourited

λ toot favourite 109397833714235268
✓ Status favourited

[danschwarz]

Easiest way to test is with two separate clients logged in to one account. Launch toot tui, navigate to a post. Now launch the Mastodon web client, same account, navigate to same post and boost it. Go back to toot tui and boost the same post. You should get the 422 error when it attempts to boost the previously boosted post. This is reproducible vs Mastodon 4.0.2 reliably for me.