I asked in #wikimedia-data-persistence about renaming the table, it looks like the rename in production is relatively difficult and should be avoided if possible.

Yeah, we for example still have old_ columns in text table from 2005 because renaming columns (or tables) is quite tricky. The reason is not that we can't do renames, actually renaming a table is quite a straightforward operation. But since there is no way to leave an alias, everything you have is going to break until mediawiki is updated to read and write from the new name which can be half an hour.

In T426102#11917602, @Ladsgroup wrote:

But since there is no way to leave an alias, everything you have is going to break until mediawiki is updated to read and write from the new name which can be half an hour.

I wonder: could we still do the rename, if we accepted a bit of breakage? This table is really low traffic (if I'm not mistaken, the last time an invitation list was created is in February; which doesn't mean this specific table wasn't accessed since February, but still...), so half an hour of breakage would be fine. Especially as long as we try to minimize that.

I'm asking nonetheless because apparently it's not common practice. Also, DatabaseUpdater doesn't have a concept of table rename (a 9yo patch proposed this but got abandoned), so I'd wanna make sure everything is still working, although I imagine we could still make that work (pretend it's a table creation rather than rename).

One way you can do it in mw, is to create a table with a new name, write a script to duplicate the table (it's rather easy) and drop the old one. It's a bit of work for you but could work. Regarding renaming in production, if you insist, I bring @Marostegui to check if there are other considerations beside the mw update breakage.

In T426102#11925563, @Ladsgroup wrote:

One way you can do it in mw, is to create a table with a new name, write a script to duplicate the table (it's rather easy) and drop the old one. It's a bit of work for you but could work. Regarding renaming in production, if you insist, I bring @Marostegui to check if there are other considerations beside the mw update breakage.

Thank you! I'd be interested in hearing any other downsides so we can make a more informed decision. Sadly, the existing table is for a closely related but distinct concept, and it would be great if we could rename it to avoid any ambiguity going forwards (considering the old one is low-traffic).

In T426102#11925563, @Ladsgroup wrote:

One way you can do it in mw, is to create a table with a new name, write a script to duplicate the table (it's rather easy) and drop the old one. It's a bit of work for you but could work. Regarding renaming in production, if you insist, I bring @Marostegui to check if there are other considerations beside the mw update breakage.

This is the ideal way of doing this.
However, having said that, the table is pretty small (9k rows) and just 9MB on disk. We can easily rename it in production but plenty of things can break from this (expected and unexpected).
@cmelo in order to understand the process better, how would your team monitor this operation and address breakages?

In T426102#11940340, @Marostegui wrote:

In T426102#11925563, @Ladsgroup wrote:

One way you can do it in mw, is to create a table with a new name, write a script to duplicate the table (it's rather easy) and drop the old one. It's a bit of work for you but could work. Regarding renaming in production, if you insist, I bring @Marostegui to check if there are other considerations beside the mw update breakage.

This is the ideal way of doing this.
However, having said that, the table is pretty small (9k rows) and just 9MB on disk. We can easily rename it in production but plenty of things can break from this (expected and unexpected).
@cmelo in order to understand the process better, how would your team monitor this operation and address breakages?

Thank you so much @Marostegui , I will let @Daimona answer it, but this table is only used in an specific feature (thas has a really low traffic), so the breakages should happen only there if people try to use it (last usage of it was in february ), we can monitor the logs to react to any breakages.

What do you think @Daimona ?

In T426102#11940340, @Marostegui wrote:

However, having said that, the table is pretty small (9k rows) and just 9MB on disk. We can easily rename it in production but plenty of things can break from this (expected and unexpected).
@cmelo in order to understand the process better, how would your team monitor this operation and address breakages?

I'll second what @cmelo said. We can do a quick round of testing as it's just an individual and self-contained feature. Are there any specific precautions or actions we should take?

In T426102#11940870, @Daimona wrote:

In T426102#11940340, @Marostegui wrote:

However, having said that, the table is pretty small (9k rows) and just 9MB on disk. We can easily rename it in production but plenty of things can break from this (expected and unexpected).
@cmelo in order to understand the process better, how would your team monitor this operation and address breakages?

I'll second what @cmelo said. We can do a quick round of testing as it's just an individual and self-contained feature. Are there any specific precautions or actions we should take?

Not from my side, for us it is just a one command on the master. But I guess you'd need to grep for places where this table is hardcoded. In puppet I just saw:

modules/mediawiki/files/mariadb/tables-catalog.yaml:  - name: ce_worklist_articles

Change #1289994 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Rename ce_worklist_articles table to ce_invitation_list_articles

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

Change #1290814 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[operations/puppet@production] tables-catalog: Rename ce_worklist_articles to ce_invitation_list_articles

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

In T426102#11940878, @Marostegui wrote:

But I guess you'd need to grep for places where this table is hardcoded. In puppet I just saw:

modules/mediawiki/files/mariadb/tables-catalog.yaml:  - name: ce_worklist_articles

Yup thanks, I made a prospective patch for that.

I also made a patch to do the rename in MW code, @Ladsgroup hopefully that's what you had in mind :) As noted in the commit message, the change is obviously not backwards compatible, so we'll coordinate with y'all to land this in production and have the table renamed immediately afterwards.

Change #1292025 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Rename 'Worklist' to 'ArticleList' in code

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

Change #1292029 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Rename "worklist" to "article list" in i18n

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

Change #1289994 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Rename ce_worklist_articles table to ce_invitation_list_articles

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

Change #1292025 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Rename 'Worklist' to 'ArticleList' in code

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

Change #1321223 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@wmf/1.47.0-wmf.13] Rename ce_worklist_articles table to ce_invitation_list_articles

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

Change #1321224 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@wmf/1.47.0-wmf.14] Rename ce_worklist_articles table to ce_invitation_list_articles

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

@Ladsgroup @Marostegui The patch has landed in master. There are quite a few changes to the table due to field prefixes changing: before, after. I have included code for migrating the records (it's not a maintenance script as it's trivial). I can copy the function and run it via shell.php or something if that works for y'all. I'll need to do it during a backport window as that involves backporting the updated code that reads from and writes to this table.

Change #1292029 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Rename "worklist" to "article list" in i18n

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

Change #1321223 abandoned by Daimona Eaytoy:

[mediawiki/extensions/CampaignEvents@wmf/1.47.0-wmf.13] Rename ce_worklist_articles table to ce_invitation_list_articles

Reason:

No longer needed

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

Change #1324325 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[operations/puppet@production] tables-catalog: Drop ce_worklist_articles

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

Should this still be considered blocking for T430834: 1.47.0-wmf.15 deployment blockers?

Change #1290814 merged by Ladsgroup:

[operations/puppet@production] tables-catalog: Add ce_invitation_list_articles

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

In T426102#12203343, @brennen wrote:

Should this still be considered blocking for T430834: 1.47.0-wmf.15 deployment blockers?

Yeah, I'd written in T430834#12191945 but not here. This task introduced a backwards incompatible change and the schema needs to be updated in production or the code would fatal trying to read a nonexistent table. I'm adding the backport to tomorrow's afternoon window, and barring objections, I'll create the table and migrate the data as described in T426102#12185841 immediately afterwards.

Where are we at with this one after the backport window?

In T426102#12206426, @brennen wrote:

Thanks @Daimona for clarification. I mistakenly assumed recently merged patches linked here represented an unblock, and should instead have waited for a response - apologies.

No problem at all!

In T426102#12208429, @brennen wrote:

Where are we at with this one after the backport window?

I spoke with Kosta who was deployer for that window. We agreed that we would like to have a DBA around for the migration just in case. Also potentially to confirm that the plan in T426102#12185841 is OK to execute.

I spoke with Kosta who was deployer for that window. We agreed that we would like to have a DBA around for the migration just in case. Also potentially to confirm that the plan in T426102#12185841 is OK to execute.

That seems sensible, but it would be much better not to have the train blocked at testwikis this far into Wednesday. Is there a revert that can be applied instead to unblock the train, if this isn't going to be handled shortly?

In T426102#12208569, @brennen wrote:

I spoke with Kosta who was deployer for that window. We agreed that we would like to have a DBA around for the migration just in case. Also potentially to confirm that the plan in T426102#12185841 is OK to execute.

That seems sensible, but it would be much better not to have the train blocked at testwikis this far into Wednesday. Is there a revert that can be applied instead to unblock the train, if this isn't going to be handled shortly?

The revert would break beta, where the table has been renamed. I suppose that's still better than blocking the train, if needed. Otherwise we could proceed with the backport and create the table in production. Existing data would become unavailable until the migration, but that should also be OK, and perhaps the best approach.

Mentioned in SAL (#wikimedia-operations) [2026-08-12T18:18:45Z] <Amir1> migrated testwiki entries from ce_worklist_articles to ce_invitation_list_articles (T426102)

Mentioned in SAL (#wikimedia-operations) [2026-08-12T18:25:03Z] <Amir1> ce_invitation_list_articles created as empty on wikishared (T426102)

Change #1321224 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@wmf/1.47.0-wmf.14] Rename ce_worklist_articles table to ce_invitation_list_articles

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

Mentioned in SAL (#wikimedia-operations) [2026-08-12T18:51:06Z] <ladsgroup@deploy1003> Started scap sync-world: Backport for [[gerrit:1321224|Rename ce_worklist_articles table to ce_invitation_list_articles (T426102)]]

Mentioned in SAL (#wikimedia-operations) [2026-08-12T18:53:15Z] <ladsgroup@deploy1003> ladsgroup, daimona: Backport for [[gerrit:1321224|Rename ce_worklist_articles table to ce_invitation_list_articles (T426102)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-08-12T18:57:57Z] <ladsgroup@deploy1003> Finished scap sync-world: Backport for [[gerrit:1321224|Rename ce_worklist_articles table to ce_invitation_list_articles (T426102)]] (duration: 06m 50s)

Mentioned in SAL (#wikimedia-operations) [2026-08-12T19:00:00Z] <Amir1> data migrated on wikishared (T426102)

In T426102#12209149, @Daimona wrote:

In T426102#12208569, @brennen wrote:

I spoke with Kosta who was deployer for that window. We agreed that we would like to have a DBA around for the migration just in case. Also potentially to confirm that the plan in T426102#12185841 is OK to execute.

That seems sensible, but it would be much better not to have the train blocked at testwikis this far into Wednesday. Is there a revert that can be applied instead to unblock the train, if this isn't going to be handled shortly?

The revert would break beta, where the table has been renamed. I suppose that's still better than blocking the train, if needed. Otherwise we could proceed with the backport and create the table in production. Existing data would become unavailable until the migration, but that should also be OK, and perhaps the best approach.

What I‌usually would do is to revert it on the branch but not master. Just an idea for future train blockers.

Anyway. It should be fixed now.

@Daimona what is left to be done here? Is this done?

In T426102#12242458, @VPuffetMichel wrote:

@Daimona what is left to be done here? Is this done?

It's almost done:

In T426102#12210144, @Daimona wrote:

The only thing left to do is to drop the old ce_worklist_articles tables (which is for DBAs to do IIUC) and remove it from the catalog.