Comment on Upcoming changes to kudos

  1. 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: https://otwarchive.atlassian.net/browse/AO3-5597

    This is the current schema for the kudos table: https://github.com/otwcode/otwarchive/blob/ecf3f58a8b6511523fc51eea2ba9d9c059e49432/db/schema.rb#L609
    - 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