Comment on Upcoming changes to kudos

  1. And re: my request for more information at the beginning of rollouts/announcements like this, I'd also like to point out the extremely worrying tweet: "We're running out of room in the kudos table, and without this change, it will no longer be possible to leave kudos."

    Although context was shortly added, that's...really something that should be more carefully considered before you tweet it. It made it sound VERY much like there was going to be an ongoing issue with kudos.

    I'm also wondering about this part:

    This means that if you have received multiple kudos from the same user or guest on one of your works, your kudos total will go down when we deploy this change.

    How do you know it's the same guest? Are you going off IP? By the timing of the kudos? I guess my concern here is that this change is going to end up stripping away more kudos than it actually should...which maybe you've accounted for very well behind the scenes, but the information provided thus far here and on twitter has done little to ease my concerns.

    I appreciate all your hard work, of course, and fully support AO3 (have for years now!). Would just like more details for this type of thing in the future so it doesn't set off mini panics.

    Last Edited Wed 11 Mar 2020 09:10PM EDT

    Comment Actions
    1. Steven Gerrard and Xabi Alonso

      I don't know anything about how stuff work, but I do know that I can't leave multiple kudos as a guest on the same fic from the same device? So there must be a way to know which kudos were left by the same guest

      Comment Actions
    2. IP address is stored if user ID is not. It will almost certainly be by IP address.

      A fear of stripping away more kudos than necessary would require some incompetence on the coding side. Really the purge amounts to check work, if in the kudos for this work, a user ID appears >1, delete the newest kudos record. Same for guest kudos, just IP instead of user ID. The IP essentially functions the same as a user ID, as you can't kudos more than once on a work from an IP address anyway.

      Comment Actions
    3. I'm not one of the volunteer coders, so I'm not super familiar with the processes here, but they do have a public Jira for project management and codebase work happens on GitHub.

      The specific ticket for organizing these changes seems to be this one:

      This is the current schema for the kudos table:
      - Looks like it's a many-to-many relationship table between pseud_id (pseudonym of a user?) and commentable_id (things like posted works?)

      My understanding that these changes were motivated by a number of existing bugs:
      - If a user leaves a kudos and then changes their username/default pseud, their name in the kudos list is still the old username
      - The kudos table was starting to run out of space (primary key currently seems to be an signed integer, which has an max value 2,147,483,647 in MySQL; for comparison, there were ~647,000,000 kudos on the site as of Feb. 14, 2020)
      - It is possible to leave duplicate kudos (if you look at the kudo model code from before the recent changes, Rails did already validate for uniqueness on pseud_id and/or ip_address; but the uniqueness is not validated at the database level, so presumably it was possible for duplicates to sneak through somehow)

      So the fix plan seems to be (according to the Jira epic):
      1. Database migration: Add user_id column to kudos table
      2. Change the code to save user_id when a new kudos is created by a logged in user
      3. Task to fill in the user_ids for existing kudos that were left by logged in users
      4. Update Rails to validate uniqueness on user_id instead of pseud_id
      5. Database migration: (1) Change primary key type from INT to BIGINT (this updates the max table size to 2^63 - 1), (2) add unique index for commentable_id + commentable_type + user_id, (3) add unique index for commentable_id + commentable_type + ip_address
      6. Task to update kudos count on indexed works (something something caching I think)
      7. Change kudos displays to use users instead of pseuds
      8. Drop the pseud_id from the kudos table

      Right now I think they're right around step 5, just before their changes might start having visible effects on the users.

      And n.b. that in that upcoming database migration, they'll be changing the primary key type from INT to BIGINT. This is how they're resolving the issue with space in the kudos table. INT is signed 32-bit, BIGINT is signed 64-bit. In other words, the max kudos table size before was 2,147,483,647 entries. The new max kudos table size will be 9,223,372,036,854,775,807 entries. i.e. after this migration, hard disk capacity will be a concern long before the max PK value does.

      Comment Actions
      1. Hm. That's interesting and helpful, thanks. It actually makes me wonder now, though, if the kudos will drop even more than expected, because while I have not exploited the multi-click kudos bug, I *have* left multiple kudos as a guest (before I had an AO3) account, then as my logged-in account on re-reading particular fics years later. I've also heard that it was possible to leave multiple kudos if you did so with enough time in between them. I suppose there's no use worrying about it, though, since it's something they have to go ahead with to ensure future kudos will continue working.

        Comment Actions
      2. Ladybug with a rainbow Pride background

        thank you for the explanation!

        Comment Actions
      3. "I dwell in darkness, Madam, and darkness is where I belong."

        Thank you for breaking this down, especially the INT to BIGINT detail; that should alleviate concern about running out of room for hits, or saying that we should just remove kudos since we're going to run out of room for them anyway.

        Comment Actions