If you're using #Pachli Current then as ever, thank you.
The latest version contains a critical bug fix. Pachli inherited a #Tusky 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.
Thank you to @weilawei@mastodon.online for posting about this (https://mastodon.online/@weilawei/111782356065284039 et al) to raise awareness of the issue, and verifying the fix in #Pachli Current works.
@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 https://github.com/pachli/pachli-android/issues/370 but the writeup in the PR is probably more helpful; https://github.com/pachli/pachli-android/pull/373
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.
@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.