Still running:

@Sgs and I discussed this during our 1:1. The problem was that the script was returning LoggedUpdateOutcome::COMPLETE even on dry-run, meaning it got logged as finished in updatelog. I removed all records of its execution again (logs are available at P94199). I also uploaded a patch that changes the script's behavior to always return SIMULATED on dry-runs.

From a 1:1 between @Michael and I, we should probably detect if the image is a PDF and if so, not return any thumbnail image.

Another possible action item here: include the DB server where the creation happened in the output. While this wouldn't prevent the issue from happening, it would allow me to double check it got created at the expected place.

This is probably closer to our Rdbms lib than to WikimediaMaintenance.

In T429302#12022853, @Urbanecm_WMF wrote:

• Declare virtual domains unconditionally: move $wgVirtualDomainsMapping declarations in CommonSettings.php outside of their respective $wmgUseXxx blocks

In T429302#12022853, @Urbanecm_WMF wrote:

I'm also curious why $lbf->getLoadBalancer( $virtualDomain ) with an unrecognized $virtualDomain returns a pointer to s3. I would expect the main section (or an error), but definitely not s3...

The accidental creation of wikidatawiki at s3 makes me think... Should the script even attempt to run CREATE DATABASE IF NOT EXISTS? I can't think of a scenario where an x1 database wouldn't already exist... addWiki.php should handle provisioning it.

This is how I located them:

Interestingly, the script (somehow) decided to create the wikidatawiki tables on s3 wikidatawiki, not on s8 wikidatawiki (as I would expect when virtualdomain points nowhere):

I located the wikidatawiki tables. For some reason, the script put them on s3 wikidatawiki:

Should I drop those?

Accidentally created the DB tables in the wrong database, but it should be done. https://www.wikidata.org/wiki/Special:Homepage is now a thing!

Details about how I managed to create them erroneously are at T429302: createExtensionTables.php makes it super-easy to accidentally create DB on wrong cluster.

I ended up having to run the maintenance script within mw-debug (where the virtual domain was already defined), and then proceed.

DB tables created:

@Michael I also applied the same fix to PraiseworthyConditionsLookup. Both should be no-ops, but it's better to not call that extra code if we don't need to. Plus, not using the User object is a good idea whenever possible.

Very unlikely. User::getBlock() is only considering IP blocks if the session user and the considered user are equal to each other. isUserIneligibleForMentorship would run on other users (for example, when assigning the mentor), or without any user (when reassignment happens in the background job).

@Arian_Bozorg have you already worked on the community configuration?

Estimaton meeting 2026-06-15: we agreed to sort the namespaces according to their internal ID instead.

@Isaac mentioned they would review the code today or tomorrow as well.

Thank you for your patience. I have published a new version of the data, which includes the new column you asked for. Unfortunately, I was not able to find out why event_sanitized.serversideaccountcreation reports created users that aren't recorded in the DB. I added a JOIN on mediawiki_user (a monthly copy of the actual user table from production), which should filter out those users. I'll fill a follow-up ticket to learn more on this.

Lowering priority. I suggest to keep this opened and unassigned, unless @Dreamy_Jazz plans on finishing the fix.

Thanks for the quick response here, @kostajh and @Dreamy_Jazz!

Blocks GrowthExperiments merges.

Bug report confirmed and rootcaused. Initially, I become suspicious this would also be affecting a similar check when the mentee is IP blocked and asks a question (if their mentor is away, it would tell them their question is redirected to someone else), but this is not the case.

With the changes by Kirsten & Benoit, let's consider this resolved.

I believe this now needs to be actually executed (once wmf.7 is on all wikis, or we need to backport it).

Finished both pages

Started

Continues to happen...

Thank you for the updates!

That is correct @KStoller-WMF. Any answer (on-wiki) is an edit, so it will be considered an activity.

And uninstalled, this is now ready for DBA to drop the tables.

Filled T428884: Remove GrowthExperiments extension from closed wikis and T428885: Drop growthexperiments_* tables from closed wikis as followups. The remaining part is to document the "alert DBA" part on the Close a wiki task. I would _love_ closing to generate one large form with all the changes though...

Follow-up to T420566 and quick enough to just do (TM).

Pending uninstalling the extension itself.

Thank you for the proposal. My name is Martin, and I'm an engineer working on the mentorship features. Unfortunately, this would be a fairly involved task. It would mean expanding Special:ManageMentors with a number of extra columns, some of which are difficult to compute. Getting the dates of responses to mentee questions is a good example: while we can find a question easily enough (it's the latest edit tagged as a question), identifying its response is challenging, since the response carries no tag of its own.

Thank you for the response and for the notebook, this is very helpful.

Pending definition of deployment dates and pending wikis. Started conversation in WMF Slack, but no decision seems to be made. Moving to blocked (cc @KStoller-WMF @Trizek-WMF).

Initial documentation created at https://www.mediawiki.org/wiki/Help:Growth/Mentorship#Automated_mentor_list_cleanup.

I started the refresh job on crhwiki and diqwiki. Thanks to T420462, we should have visibility into similar issues if/when they happen.

Moving to sprint for QA purposes.

Deployed to production. Now it works:

Back to Code Review for @AAlhazwani-WMF's changes.

Users in dataset.tsv with no row in growthexperiments_mentor_mentee

Thank you so much for the review! This is appreciated. I changed the convert_up_property() function to the following:

I have finally got to this task and prepared the dataset. I published my outputs at https://analytics.wikimedia.org/published/datasets/one-off/growth/growthexperiments-mentorship-enabled-T420387/. Both the Jupyter notebook and the dataset are published there.

Removed the extra training dependencies and verified it works:

As it's already done.