(1) We may also want to keep such tables in Meta-Wiki, or alternative they need to be recreated after T335002: Move SecurePoll election setup from votewiki to metawiki.
(2) We also need to make sure no new such tables are created in new wikis.

Change #1174433 merged by jenkins-bot:

[mediawiki/extensions/SecurePoll@master] DropUnusedTables: add --dry-run option

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

Change #1174441 had a related patch set uploaded (by Ladsgroup; author: Novem Linguae):

[mediawiki/extensions/SecurePoll@wmf/1.45.0-wmf.11] DropUnusedTables: add --dry-run option

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

Change #1174442 had a related patch set uploaded (by Ladsgroup; author: Novem Linguae):

[mediawiki/extensions/SecurePoll@wmf/1.45.0-wmf.12] DropUnusedTables: add --dry-run option

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

Change #1174441 merged by jenkins-bot:

[mediawiki/extensions/SecurePoll@wmf/1.45.0-wmf.11] DropUnusedTables: add --dry-run option

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

Change #1174442 merged by jenkins-bot:

[mediawiki/extensions/SecurePoll@wmf/1.45.0-wmf.12] DropUnusedTables: add --dry-run option

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

Mentioned in SAL (#wikimedia-operations) [2025-07-30T12:03:46Z] <ladsgroup@deploy1003> Started scap sync-world: Backport for [[gerrit:1174442|DropUnusedTables: add --dry-run option (T395928)]], [[gerrit:1174441|DropUnusedTables: add --dry-run option (T395928)]]

Mentioned in SAL (#wikimedia-operations) [2025-07-30T12:05:56Z] <ladsgroup@deploy1003> ladsgroup: Backport for [[gerrit:1174442|DropUnusedTables: add --dry-run option (T395928)]], [[gerrit:1174441|DropUnusedTables: add --dry-run option (T395928)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-07-30T12:12:07Z] <ladsgroup@deploy1003> Finished scap sync-world: Backport for [[gerrit:1174442|DropUnusedTables: add --dry-run option (T395928)]], [[gerrit:1174441|DropUnusedTables: add --dry-run option (T395928)]] (duration: 08m 20s)

Decent amount of progress. Worth noting that I'm getting this for basically all wikis I'm running this on:

⏳ Starting extensions/SecurePoll/maintenance/DropUnusedTables.php on Kubernetes as job mw-script.eqiad.a2yy1rkv ...
🚀 Job is running.
📜 Streaming logs:
Would have dropped table rnwiktionary.securepoll_cookie_match, but we are in dry-run mode.
Table rnwiktionary.securepoll_entity is not empty, skipping.
Table rnwiktionary.securepoll_options is not empty, skipping.
Table rnwiktionary.securepoll_questions is not empty, skipping.
Would have dropped table rnwiktionary.securepoll_strike, but we are in dry-run mode.
Would have dropped table rnwiktionary.securepoll_voters, but we are in dry-run mode.
Would have dropped table rnwiktionary.securepoll_votes, but we are in dry-run mode.

These three tables are almost never empty. Would someone mind taking a look why that could be? if it's garbage/test, if you delete the rows, that'd make things much better.

I don't have production read access yet so can't look directly. What kind of row counts are we looking at for those tables?

Hypothesis to check: maybe redirect polls create local copies of each global election, filling these 3 tables.

Another hypothesis to check: maybe redirect polls USED TO create local copies of each global election, then the code changed to not do that anymore

I dropped these tables

I wait until dropping the next round

In T395928#11046636, @Ladsgroup wrote:

These three tables are almost never empty. Would someone mind taking a look why that could be? if it's garbage/test, if you delete the rows, that'd make things much better.

'election'-type entities are saved to securepoll_entities even for redirect polls. Missed it earlier as it's being done in a helper function. I don't yet see any code that write to securepoll_options or _questions though.

I dropped these tables

Note T400831 - I'm seeing securepoll_votes doesn't exist errors for some wikis on the above list, e.g. xhwiktionary.

Yes, turns out the securepoll_votes table also gets read for redirect polls on Special:SecurePoll/list, although pointlessly since the query would always return 0 rows, since T75915/T398126 haven't been resolved.

It sounds hard to restore the tables that have already been deleted. I think the better solution is to fix it to show an info/warning message (that the vote list is available on the votewiki).

I intentionally dropped the table in group0 to avoid wide-spread issues so no worries on this getting this becoming a bigger problem. I can re-create them since they were all empty but I rather not do that as there is a reason we want to drop them in the first place (T395929). Can that code path wrapped around with a ->tableExists()? It'd require IMaintainableDatabase interface though.

Didn't cc this ticket, but I have raised a patch in T400831 which fixes the issue properly.

I think the issue with the Special:SecurePoll/list pages is sorted.

Thank you! Is it okay if I move forward to rest of s3? (all of the exceptions aside)

Production error: T400907: Table 'securepoll_questions' doesn't exist (MediaWiki\Extension\SecurePoll\Store\DBStore::getQuestionInfo)

Note that there's a SecurePoll code freeze coming up tomorrow: T399610: Code Freeze for SecurePoll during Board Elections in September 2025

As a alternative we can just uninstall SecurePoll from closed wikis and non-SUL wikis, this will solve many of immediate problems.

I'm planning to move forward with this today or tomorrow (depending on the will of the god of outages)

FYI, SecurePoll code freeze doesn't end until Sept 10 end of day. T399610: Code Freeze for SecurePoll during Board Elections in September 2025.

In T395928#11115455, @Novem_Linguae wrote:

FYI, SecurePoll code freeze doesn't end until Sept 10 end of day. T399610: Code Freeze for SecurePoll during Board Elections in September 2025.

I think this would not apply to that kind of backend work as it wouldn't impact UX.

Working on this ticket has previously caused SecurePoll production errors. For example T400907 and T400831. But anyway, sounds like the code freeze has been turned off until Sep 1, so that gives Ladsgroup a window to work on this ticket :)

Thanks. I move forward with the drop now.

Does this make sense? There are three tables that supposed to be empty and droppable but they aren't:

zuwiktionary Would have dropped table zuwiktionary.securepoll_cookie_match, but we are in dry-run mode.
zuwiktionary Table zuwiktionary.securepoll_entity is not empty, skipping.
zuwiktionary Table zuwiktionary.securepoll_options is not empty, skipping.
zuwiktionary Table zuwiktionary.securepoll_questions is not empty, skipping.
zuwiktionary Would have dropped table zuwiktionary.securepoll_strike, but we are in dry-run mode.
zuwiktionary Would have dropped table zuwiktionary.securepoll_voters, but we are in dry-run mode.
zuwiktionary Would have dropped table zuwiktionary.securepoll_votes, but we are in dry-run mode.

In T395928#11121946, @Ladsgroup wrote:

Does this make sense? There are three tables that supposed to be empty and droppable but they aren't:

I had a look. In zuwiktionary:

select * from securepoll_questions limit 100;
+-----------+-------------+----------+
| qu_entity | qu_election | qu_index |
+-----------+-------------+----------+
|         2 |           1 |        1 |
|         7 |           6 |        1 |
|        18 |          17 |        1 |
|       201 |         200 |        1 |
|       231 |         230 |        1 |
+-----------+-------------+----------+

If we go to https://zu.wiktionary.org/wiki/Special:SecurePoll these elections match up:

None of these elections were set up or run through votewiki so I assume they were set up locally. They are extremely old and the only thing in at least that table, so probably still OK to drop.

The other option would be to skip zuwiktionary when running the maintenance script. That is, make it so they keep all 12 of their SecurePoll tables. That would preserve the data.

Perhaps we should also start a list somewhere of which wikis will still have all their SecurePoll tables after this cleanup. Then we can add to that list as wikis file tickets to enable local elections.

In T395928#11127012, @Novem_Linguae wrote:

The other option would be to skip zuwiktionary when running the maintenance script. That is, make it so they keep all 12 of their SecurePoll tables. That would preserve the data.

Perhaps we should also start a list somewhere of which wikis will still have all their SecurePoll tables after this cleanup. Then we can add to that list as wikis file tickets to enable local elections.

They can instead firstly be backup somewhere and then dropped.

I'd be in favor of keeping old elections instead of deleting them, assuming that there's just a couple wikis with this issue. We'd still get to delete thousands of tables. And we'd also get to preserve the history of the few wikis that had elections (i.e. someone could go to Special:SecurePoll on that wiki and view the old elections).

I also spotted something else. Currently our maintenance script checks 8 tables to see if they can be dropped, and may decide to only drop a couple of those 8 tables. I think that could leave SecurePoll in a weird state if it has local elections. It would probably throw a lot of exceptions if you tried to view or do things to those local elections with these tables missing. I think I'm going to write a patch to the maintenance script to make it behave more "all or nothing" when deciding what tables to delete for each wiki. Will upload the patch in a few minutes.

If they are intended to be tests only, I see no points to keep those local elections.

At first glance these looked like real local elections to me. But looking again more closely, these might be global elections. So not sure what's going on here. Not sure why just this wiki has local copies of global elections.

Change #1182687 had a related patch set uploaded (by Novem Linguae; author: Novem Linguae):

[mediawiki/extensions/SecurePoll@master] DropUnusedTables: avoid only dropping some tables

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

In T395928#11121946, @Ladsgroup wrote:

Does this make sense? There are three tables that supposed to be empty and droppable but they aren't:

I don't see anything particularly unusual with zuwiktionary. Almost all wikis have the same problem - you observed that in T395928#11046636. Securepoll_questions and options have identical content on most wikis from the time of pre-votewiki central elections.

In T395928#11126996, @jrbs wrote:

If we go to https://zu.wiktionary.org/wiki/Special:SecurePoll these elections match up:

Election ID	Election
Personal image filter referendum, 2011	230
Wikimedia Board of Trustees Election, 2011	200
Wikimedia Board of Trustees Election, 2009	17
Wikimedia license update vote 2009	1
Test vote	6

None of these elections were set up or run through votewiki so I assume they were set up locally. They are extremely old and the only thing in at least that table, so probably still OK to drop.

These aren't local elections. See the link in https://zu.wiktionary.org/wiki/Special:SecurePoll/list/230 – they appear to have been run through a different website (wikimedia.amellus.net).

Change #1182688 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/extensions/SecurePoll@master] DropUnusedTables: don't try to drop securepoll_entity

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

In T395928#11127228, @SD0001 wrote:

In T395928#11121946, @Ladsgroup wrote:

Does this make sense? There are three tables that supposed to be empty and droppable but they aren't:

I don't see anything particularly unusual with zuwiktionary. Almost all wikis have the same problem - you observed that in T395928#11046636. Securepoll_questions and options have identical content on most wikis from the time of pre-votewiki central elections.

So we can just left copy in one wiki, which is metawiki (where polls in votewiki will be migrated, see T335002).

Mentioned in SAL (#wikimedia-operations) [2025-09-03T13:45:49Z] <Amir1> dropping all unused tables of securepoll in s3 (T395928)

I just dropped these tables: