mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

279K
active users

Pachli

If you're using Current then as ever, thank you.

The latest version contains a critical bug fix. Pachli inherited a bug; in some situations it is possible for an action (boost, favourite, reply) etc to be applied to the **wrong** post.

You'd think you were boosting post A, but actually boosting post B.

Assuming no issues are reported with Pachli Current then version 2.2 with this fix will be released on Monday 29th Jan.

@pachli Are there any details about the circumstances which trigger it (link to GitHub issue, for example)? I'm posting this from a non-Pachli client just in case, but perhaps that is unduly paranoid given that I haven't (that I've noticed) hit this bug despite using Pachli daily since roughly the time of the fork from Tusky.

@soaproot GH issue is github.com/pachli/pachli-andro but the writeup in the PR is probably more helpful; github.com/pachli/pachli-andro

tl;dr: Potential for a race condition if you interact with a post at the same time as new posts are loading, as actions were applied to a post based on its position in the timeline.

So if you tapped to boost post number 10 in the list, and in the time between you tapping and Pachli making the API call new posts were loaded above then post 10 might be completely different.

GitHubPost actions operating on the wrong post · Issue #370 · pachli/pachli-androidBy nikclayton

@soaproot It does seem to be rare, as no one else reported the issue with Pachli, and I don't recall anyone reporting the problem with Tusky before.

But it's also a difficult bug to notice; the UI would show the boost happened on the expected post, and unless you went and checked your profile to see what you'd posted (or someone sent you a "Hey, why did you boost that?" message).

I view this as a serious privacy issue, so fixing it was high priority.

@soaproot The Pachli codebase is now sufficiently different from Tusky that the Tusky team will not be able to simply copy over the fixed code, but there should be enough information in the PR description and the diff that it should be straightforward for them to implement it in Tusky.

If it's not, and given the privacy risk this poses to users, I'm happy to consult with whoever on the Tusky side is writing the fix so they can implement it and speedily deploy it.

@pachli Thanks! That's very clear. My guess is that I can wait a few days for the fixed Pachli to be out without too much worry because I tend to wait until operations (apparently) complete before doing something else. And my (mostly unsubstantiated, just based on your description) guess is that the people who are seeing it multiple times a day are much quicker to tap on things. Agree this is a serious bug regardless of its rarity.