4
$\begingroup$

After migrating this Q&A from Crypto.SE to Security.SE, I accidently noticed a bug/glitch related to migrated Q&As. Practically, this glitch - which needs either a bugfix or an explanation related to the logic behind it - allows to skew reputation across SE sites.

Since this bug/glitch is related to the SE core functionality, it can only be fixed by the SE dev team.

Reproducing the bug

  1. Vote for a question and/or answer at an SE site.
  2. Assume the question gets migrated to another SE site
  3. You can now vote the same question and answer(s) again, even though you already voted on them at the original site.

This boils down to "the ability to double-vote migrated Q&As".

Something tells me this isn't the way it should work, since it skews reputation for the involved users and opens the door to cheating, as it gives the posting users of such Q&As an unfair advantage even though their Q was clearly "off-topic" at the originating site.

How to fix it quick and easy

Fixing this bug is pretty simple: reset all votes when a Q&A is migrated, so that a migrated question and potential answers are at 0 after migration.

This also makes sense, at it would remove the votes/reputation at the originating site, where the Q&A was off-topic; which is the reason for migration in the first place.

From a coding/design point of view, it wouldn't be more complicated or resource hungry as what the SE code already does when a Q&A gets deleted, or merged, or a user account gets removed/deleted...

  1. At originating site, drop all Q&A-related votes and accordingly recalc reputation of the few users who voted; if any.
  2. Migrate the (now virgin, zero-votes) Q&A as already implemented.

Done.
(aka That moment when a KISS principle voids potential "by design" arguments.)

Coding hint

Here's a coding hint to show there aren't any bottlenecks you might be seeing: Step 1 can be partly cron-jobbed as user reputation recalculation doesn't have to happen instantly.

In a worst case (depending on how messy SE code and DB structures are implemented), the same user would have a cronned rep recalc at two individual sites.

Only the Q&A votes need instant zero-fying/reset using a single, non-complicated DB call before migration (as already implemented) in step 2.

All in all it's pretty simple to fix this glitch. That is, from my personal point of view (speaking as a multi-platform software architect, not as a Crypto.SE mod).

Fun fact

SE has alike code running already. See cron-jobbed rep recalc when "user removed/deleted" and "Q or A deletion". It merely takes some minimal motivation and a tiny bit of glue to copy-and-paste existing code snippets into a bugfix for the whole SE network. (read: "all SE sites" would be fixed with a single bugfix in one of the functions of the SE core that all the - curently 161 - communities run upon.)

Last but not least

As I was able to describe how to fix it while avoiding all resource- and coding-related pitfalls (something that took less than a minute to wrap up in my brain), not fixing the glitch doesn't really seem to make sense.

Therefore... in the unlikely case SE wants to handle this as "not a bug" or "by design", I would definitely appreciate a darn good explanation about the reasoning for this "feature" and any potential logic SE might be seeing... and which I would obviously be missing in that case. One thing is clear: the well-vetted and frequently used arguments going "complicated DB calls with cross-site complications" and/or "coding is difficult" definitely aren't applicable in this case (see my "How to fix it quick and easy" above to grasp why such arguments don't fit in this case).

$\endgroup$
7
  • $\begingroup$ Apparently it's [status-broken-by-design] $\endgroup$
    – CodesInChaos
    Dec 3, 2016 at 15:59
  • $\begingroup$ @CodesInChaos Apoarently, they forgot the KISS principle. Added edit explaining "how to fix it" $\endgroup$
    – e-sushi
    Dec 3, 2016 at 16:10
  • $\begingroup$ It's probably difficult to implement due to their messed up multi-site implementation (global vs site specific user-id), so I can understand them being unwilling to fix it. But declaring it by-design is truly WTF. $\endgroup$
    – CodesInChaos
    Dec 3, 2016 at 16:12
  • $\begingroup$ @CodesInChaos It's not difficult at all. The fix I described doesn't need any additional cross-site DB mingling, which voids that argument in its roots. (Fun fact: SE has alike code running already. Edited that in too.) $\endgroup$
    – e-sushi
    Dec 3, 2016 at 16:17
  • $\begingroup$ @Oded You might have missed the part asking for an explanation which I can forward to users when they ask us mods about this. Quote: In the unlikely case SE wants to handle this as "not a bug" or "by design", I would definitely appreciate a darn good explanation about the reasoning for this "feature" and any potential logic SE might be seeing... See, I was asked by two users on the same day I noticed this bug and my research showed SE failed to explain this for the past 7 years. Frankly, ignoring things and simply adding a "by design" tag doesn't really help explain this "glitch" to users! $\endgroup$
    – e-sushi
    Dec 6, 2016 at 2:31
  • $\begingroup$ @e-sushi - On the technical level we try very hard to ensure sites are not tied to each other (which helps us manage them effectively). This is one reason we have very little in interactions between sites. We also don't see a problem with a single post getting upvoted multiple time by the same user because this happens on different sites - the most that will happen is that the post OP will gain those 10 reputation points on two sites. $\endgroup$
    – Oded
    Dec 6, 2016 at 13:38
  • $\begingroup$ @Oded While I fail to grasp the reasoning behind that, I appreciate your attempt to explain things. tnx $\endgroup$
    – e-sushi
    Dec 6, 2016 at 13:41

1 Answer 1

Reset to default
1
$\begingroup$

Your proposed fix doesn't actually prevent duplicate votes; it just throws away all voting, whether or not those votes would've ever been duplicated. Which... Does have a certain appeal, as long as nothing you've worked hard on and seen well-received by your community is ever migrated.

Fixing this properly - actually tracking vote ownership across sites - would be considerably more complicated... Although not impossible; changes to the account system over the years have made such things somewhat more reliable... However, at this point it would not be worth the engineering effort.

Truth is, migration should be rare. Migration of established (and heavily-voted) posts should be even more rare. Quite honestly, the entire migration system (as we know it) should probably just die; it was created for a time when we were breaking off larger topics into smaller sites, and is a poor fit for the current use-cases.

$\endgroup$
2
  • 2
    $\begingroup$ Related: Killing Mary Anne. (Also, a typo in "received" here.) $\endgroup$
    – user21894
    Dec 6, 2016 at 16:17
  • $\begingroup$ The "origin of the migration feature" part explains the status quo. Thanks for taking the time to expand on this; much appreciated. $\endgroup$
    – e-sushi
    Dec 6, 2016 at 17:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .