Page MenuHomePhabricator

readinglists-db-error-already-set-up when a new user clicks on Save article button
Closed, ResolvedPublicBUG REPORT

Description

Notes:

  • a user is able to add an article to a RL on the second try
  • a similar error was resolved in T418930

Steps to replicate the issue:

  • On enwiki beta or locally on the ReadingLists master branch, create a new account.
  • Go to an article and click the bookmark button

What happens?:

  • You'll see the error:

Screenshot 2026-04-28 at 5.15.03 PM.png (1×708 px, 238 KB)

An error has occured:<readinglists-db-error-already-set-up>

What should have happened instead?:

  • a user should be able to add an article to a reading list
  • a user should not see such technical messages

Note: I've reproduced this both on beta enwiki and locally, desktop and mobile, creating an account by going directly to the account creation page and via the Account Creation CTA dialog.

Event Timeline

I don't think this is related to the experiment - I just created a new account on beta enwiki (not via the account creation CTA dialog), then tried to save an article, and saw the same error.

SToyofuku-WMF subscribed.

Grabbing this as discussed in eng enclave - I'm not positive it'll be done before the end of the sprint, but I'll do what I can

Also, if anyone wants to pair/shadow I extended an offer and will reiterate that here

(ignore the time stamp it is after 5pm eastern and I am not here 😶)

AnneT renamed this task from Account Creation CTA: readinglists-db-error-already-set-up when a new user clicks on Save article button to readinglists-db-error-already-set-up when a new user clicks on Save article button.Tue, May 5, 1:05 PM
AnneT updated the task description. (Show Details)

What's happening

The following happens when you create an account:

  • You're taken back to whatever page you were on
  • The onSkinTemplateNavigation__Universal handler in ReadingLists runs, which looks for a default list ID. If that's null, it runs ReadingListRepository::setupForUser(), which takes a param, $silent . This method first checks for a default list - if one exists, it either returns the default list or throws the exception we're seeing in this bug report.
// Bypass the setup process if the default list already exists
if ( $defaultListId !== false ) {
    // Older code may expect the exception behavior, so only return if $silent = true
    if ( $silent ) {
        return $this->selectValidList( $defaultListId, IDBAccessObject::READ_LATEST );
    }

    throw new ReadingListRepositoryException( 'readinglists-db-error-already-set-up' );
}
  • So, now the user has a default reading list. However, if they click the bookmark button immediately (without loading a new page or reloading this one), the bookmark button element will not have a data attribute with the default list id yet. Therefore, on click, it will make an API call that runs ReadingListRepository::setupForUser() with $silent = false.

Scope

I can reproduce this locally and on enwiki beta. I have not reproduced it on production enwiki. I've gone back in time locally and this issue has existed for at least a month, so I'm not sure why it's not failing on production.

What to do

A simple solution would be to ensure that ReadingListRepository::setupForUser() runs with $silent = true for ApiReadingListsSetup. Based on the comment in the code snippet above, I'm not sure why this wasn't done initially, but it seems like we should just return the default list instead of throwing an exception when a default list is found on setup.

Change #1282996 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[mediawiki/extensions/ReadingLists@master] Return default list from setup API if it exists

https://gerrit.wikimedia.org/r/1282996

Change #1282996 merged by jenkins-bot:

[mediawiki/extensions/ReadingLists@master] Return default list from setup API if it exists

https://gerrit.wikimedia.org/r/1282996

AnneT removed AnneT as the assignee of this task.Tue, May 5, 5:31 PM

Thanks again to @Etonkovidova for identifying this issue!

Thank you, @AnneT! Checked in enwiki beta - the bug is fixed.

Checked the cases

  • with ?mpo=account-creation-reading-list-cta:treatment and with control
  • in incognito window
  • with cleared browsing data
  • a temp user when a temp user created an account after publishing an edit
HFan-WMF claimed this task.