Author name is not updated in existing songs after changing username

[Bentroen]

Issue

As part of the song upload process, the user's username is 'baked' into their uploaded songs' Author field. However, when a user updates their username, existing songs are not updated to reflect this change, and still show the old username when downloaded or opened in Note Block Studio.

Although a warning is shown to the user during the username edit (as shown above), this discrepancy does not contribute to a good user experience overall. Besides this warning being quite easy to miss, it's reasonable for a user to expect their username change to reflect across all places on the website, and for no trace of their previous username to remain - especially considering the website may use part of their email address as their initial username.

Transferring the load of 'making an edit to their existing songs' onto the user due to a technical limitation (no reason that's obvious to them) is not a responsibility that they should have to bear, and not an experience we'd like to provide. Instead, this should be handled seamlessly by the service, prompting no additional user action. Keeping their username up-to-date is a responsibility that can be expected from the website.

This issue describes the requirements for fixing the issue, some considerations about possible approaches to take, and a detailed plan of action to be followed when implementing a fix.

Discussion

Fixing this issue is tricky because it requires all existing songs to be updated after a username change. This can be done in two ways:

• an immediate routine run after each username change (faster to update, but more demanding); or
• a non-synchronous routine run periodically to update out-of-date songs.

Either approach could prove costly for a user with hundreds of songs uploaded. Keeping songs up-to-date will only grow worse the longer the website is up, because each active user is more likely to have more songs uploaded on their account. Despite this, it's not something impossible to achieve.

There is, however, something that aggravates the problem: although we did plan ahead for there to be a system like this in place, the urgency for the username change feature prompted us to ship it without such a system in place. This means every song on the website must be checked for discrepancies between the username and the author field (more on it in the next section).

A relief

The good thing is: not every song-bearing user has changed their username in their history on the website, and it's possible to know which users have changed their username via their lastEdited field.

Incidentally, this is only possible because changing the username is the only action that updates this field at the moment, precisely in the line below:

NoteBlockWorld/server/src/user/user.service.ts

Line 223 in 8b74f95

user.lastEdited = new Date();

So if this field is greater than the user's creation date, we know for sure that they have updated their username at least once. This lets us filter songs uploaded by these authors before their profile's lastEdited date. Every song that needs updating will be returned by this query.

But be wary: if other kinds of profile updates are shipped before this issue is resolved, it could make it even harder to determine which songs need to be updated, as profile edits would no longer necessarily imply a username change. Thus, making sure this approach is still viable would require keeping track of the information provided by this field somewhere else.

Approach

The following section details a plan of action to follow when implementing this change.

Preparation

Right now, in order to know which songs need updating, we need to verify if their Author field diverges from their uploader's current username. This is only possible by downloading and reading the song files, since the author name is not currently duplicated in the database (the 'Author' field displayed in the song's page is actually grabbed from the uploader's username).

To make it easier to find which songs need updating, a pre-processing step could be applied to store this information as a database field, eliminating the need to download a song to check if it needs to be updated. Here are possible steps to achieve this:

• Create a new field in the songs database collection: song.stats.fileAuthor (or song.author)
• Add logic to write song.stats.fileAuthor to the document for new uploads
• Run a routine to iterate all existing songs, download them, and write their current 'Author' name to this field

Once in possession of this information, it's much easier to perform an actual update on the songs that need it.

Actual fix

As detailed above, there are two approaches we can take:

• Option 1: Write a daily routine to check songs with differing uploader.username and fileAuthor, and update those that need changes.

  • ✅ Pro: Doesn't require specific logic to update existing songs, as current and future songs will be treated equally
  • ✅ Pro: Minimizes unnecessary updates in case a user changes their username multiple times in a day
  • ⚠ Con: Costlier to run the query the more songs there are on the website.
  • ⚠ Con: There will still be a short time between updates where the Author field will be out-of-date.
  • ℹ Consideration: This routine can be completely separate from the backend's logic, even performed by a separate script.

• Option 2: Run username update routine synchronously after every update change

  • ✅ Pro: Author updates are immediate - minimizes time with discrepant information
  • ✅ Pro: Doesn't require a complex query to determine which songs need to be updated (it's just all songs previously uploaded by this user)
  • ⚠ Con: Separate logic needs to be written to handle existing songs
  • ⚠ Con: A lot of CPU could be wasted during normal operation to make this change - especially if a user has hundreds of songs, or updates their username too often.

Choosing an option

When considering which approach to go with from the two, it's wise to balance the necessary resources to run an update routine with such frequency, considering it can be quite costly, and the need for this information to be up-to-date.

Let's consider the following, then:

• Username changes are done quite sparingly.
• It's not that urgent for existing songs to become up-to-date - considering we currently don't update any existing songs at all, a few hours or at most a day is something quite bearable, provided a warning is given to reflect this behavior.
• Logic will already be in place so that new uploads already use the updated username.
• With the username edit system already in place, most users should update their username before even making their first upload, which should minimize the number of songs that need an update.
• Running the logic synchronously will become more expensive the more users with many songs there are on the website - which is expected to only grow with time.

As such, Option 1 is likely the best approach to take, balancing resources spent on updates with the timeliness required by the information at hand. Since it defers the update to a later moment, it's possible to delay it until a more appropriate time - e.g. when there are less active users -; adjust the frequency at which it runs to be higher or lower, depending on the demand; or even break up the pending songs into batches.

Post-fix

After this fix is implemented, a few additional tweaks are needed to close it all off before the change is shipped:

• Remove warning on username edit screen (or edit it to reflect that there's a small timeframe between the update and the changes reflecting)
• It would also be worth it to implement a username change throttle (e.g. three times every seven days?) to mitigate the need for updates, considering the change described here is to make username changes a costlier operation.