Page MenuHomePhabricator

RuntimeException: Event should have only one address.
Closed, ResolvedPublicPRODUCTION ERROR

Description

Error
  • service.version: 1.45.0-wmf.14
  • timestamp: 2025-08-18T22:02:06.149Z
  • labels.phpversion: 8.1.33
  • trace.id: ddbb98e0-c0ed-48ff-bcf6-dfa699318c6b
  • Find trace.id in Logstash
labels.normalized_message
[{reqId}] {exception_url}   RuntimeException: Event 1836 should have only one address.
FrameLocationCall
from/srv/mediawiki/php-1.45.0-wmf.14/extensions/CampaignEvents/src/Address/AddressStore.php(239)
#0/srv/mediawiki/php-1.45.0-wmf.14/extensions/CampaignEvents/src/Event/Store/EventStore.php(293)MediaWiki\Extension\CampaignEvents\Address\AddressStore->getAddressesForEvents(Wikimedia\Rdbms\DBConnRef, array)
#1/srv/mediawiki/php-1.45.0-wmf.14/extensions/CampaignEvents/src/Pager/EventsListPager.php(203)MediaWiki\Extension\CampaignEvents\Event\Store\EventStore->newEventsFromDBRows(Wikimedia\Rdbms\DBConnRef, Wikimedia\Rdbms\MysqliResultWrapper)
#2/srv/mediawiki/php-1.45.0-wmf.14/extensions/CampaignEvents/src/Pager/EventPagerTrait.php(145)MediaWiki\Extension\CampaignEvents\Pager\EventsListPager->doExtraPreprocessing(Wikimedia\Rdbms\MysqliResultWrapper)
#3/srv/mediawiki/php-1.45.0-wmf.14/includes/pager/IndexPager.php(297)MediaWiki\Extension\CampaignEvents\Pager\EventsListPager->preprocessResults(Wikimedia\Rdbms\MysqliResultWrapper)
#4/srv/mediawiki/php-1.45.0-wmf.14/includes/pager/IndexPager.php(846)MediaWiki\Pager\IndexPager->doQuery()
#5/srv/mediawiki/php-1.45.0-wmf.14/extensions/CampaignEvents/src/Pager/EventsListPager.php(384)MediaWiki\Pager\IndexPager->isNavigationBarShown()
#6/srv/mediawiki/php-1.45.0-wmf.14/extensions/CampaignEvents/src/Special/SpecialAllEvents.php(354)MediaWiki\Extension\CampaignEvents\Pager\EventsListPager->getNavigationBar()
#7/srv/mediawiki/php-1.45.0-wmf.14/extensions/CampaignEvents/src/Special/SpecialAllEvents.php(213)MediaWiki\Extension\CampaignEvents\Special\SpecialAllEvents->getAccordionTemplate(MediaWiki\Extension\CampaignEvents\Pager\OngoingEventsListPager, Wikimedia\Message\MessageValue, Wikimedia\Message\MessageValue, string, bool)
#8/srv/mediawiki/php-1.45.0-wmf.14/extensions/CampaignEvents/src/Special/SpecialAllEvents.php(74)MediaWiki\Extension\CampaignEvents\Special\SpecialAllEvents->getFormAndEvents()
#9/srv/mediawiki/php-1.45.0-wmf.14/includes/specialpage/SpecialPage.php(725)MediaWiki\Extension\CampaignEvents\Special\SpecialAllEvents->execute(null)
#10/srv/mediawiki/php-1.45.0-wmf.14/includes/specialpage/SpecialPageFactory.php(1729)MediaWiki\SpecialPage\SpecialPage->run(null)
#11/srv/mediawiki/php-1.45.0-wmf.14/includes/actions/ActionEntryPoint.php(499)MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, MediaWiki\Context\RequestContext)
#12/srv/mediawiki/php-1.45.0-wmf.14/includes/actions/ActionEntryPoint.php(143)MediaWiki\Actions\ActionEntryPoint->performRequest()
#13/srv/mediawiki/php-1.45.0-wmf.14/includes/MediaWikiEntryPoint.php(198)MediaWiki\Actions\ActionEntryPoint->execute()
#14/srv/mediawiki/php-1.45.0-wmf.14/index.php(58)MediaWiki\MediaWikiEntryPoint->run()
#15/srv/mediawiki/w/index.php(3)require(string)
#16{main}
Impact
Notes

Event Timeline

Restricted Application added a subscriber: Aklapper. ยท View Herald TranscriptAug 18 2025, 10:04 PM

It can't be that edit because the event metadata is updated/stored separately, but indeed:

wikiadmin2023@10.64.48.161(wikishared)> select * from ce_event_address where ceea_event = 1836;
+---------+------------+--------------+
| ceea_id | ceea_event | ceea_address |
+---------+------------+--------------+
|    2452 |       1836 |           11 |
|    2198 |       1836 |          595 |
+---------+------------+--------------+
2 rows in set (0.001 sec)
wikiadmin2023@10.64.48.161(wikishared)> select * from ce_address where cea_id in (11,595);
+--------+------------------+-------------+------------------+
| cea_id | cea_full_address | cea_country | cea_country_code |
+--------+------------------+-------------+------------------+
|     11 |                  | NULL        | CI               |
|    595 |                  | NULL        | CI               |
+--------+------------------+-------------+------------------+
2 rows in set (0.001 sec)

So most probably a bug in the deduplication logic. I'll check what it is, but for the time being, the duplicate rows can (and should!) be dropped:

delete from ce_event_address where ceea_id = 2198;
delete from ce_address where cea_id = 595;
wikiadmin2023@10.64.48.161(wikishared)> select * from ce_event_address where ceea_address in (11,595);
+---------+------------+--------------+
| ceea_id | ceea_event | ceea_address |
+---------+------------+--------------+
|      19 |         14 |           11 |
|    1788 |       1380 |          595 |
|    2098 |       1711 |          595 |
|    2169 |       1810 |          595 |
|    2197 |       1835 |          595 |
|    2452 |       1836 |           11 |
|    2198 |       1836 |          595 |
|    2283 |       1935 |          595 |
+---------+------------+--------------+
8 rows in set (0.001 sec)

So, the correct queries are:

update ce_event_address set ceea_address = 595 where ceea_id = 19;
delete from ce_event_address where ceea_id = 2452;
delete from ce_address where cea_id = 11;

I'm going to run these now.

Mentioned in SAL (#wikimedia-operations) [2025-08-18T22:40:03Z] <Daimona> Manually dropping DB rows in wikishared causing fatals # T402239#11096385

Done and confirmed that no other events are affected:

wikiadmin2023@10.64.32.36(wikishared)> update ce_event_address set ceea_address = 595 where ceea_id = 19;
Query OK, 1 row affected (0.003 sec)
Rows matched: 1  Changed: 1  Warnings: 0

wikiadmin2023@10.64.32.36(wikishared)> delete from ce_event_address where ceea_id = 2452;
Query OK, 1 row affected (0.002 sec)

wikiadmin2023@10.64.32.36(wikishared)> delete from ce_address where cea_id = 11;
Query OK, 1 row affected (0.002 sec)

wikiadmin2023@10.64.32.36(wikishared)> select ceea_event from ce_event_address group by ceea_event having count(*) > 1;
Empty set (0.001 sec)

Still investigating how this came to be in the first place.

Daimona lowered the priority of this task from Unbreak Now! to High.Aug 18 2025, 11:20 PM

Lowering priority now that the immediate issue has been fixed. Explanation and next steps coming soon.

It took me a while, but I could finally reproduce this. The steps are:

  • Set country migration stage to MIGRATION_OLD in LocalSettings
  • Create an event, set it to in person, leave the address blank and as country write "Algรฉrie"
  • Create a separate event, also in-person, leave the address blank and as country enter "Algeria"
    • This will create a new address row
  • Set the country migration stage to MIGRATION_WRITE_BOTH in LocalSettings
  • Run the migration script: php maintenance/run.php CampaignEvents:UpdateCountriesColumn --commit
    • This should migrate both rows, and the end result should be the same for both
  • Next go to Special:EditEventRegistration for the second event you created
    • It is important to note that this won't work for the first event. More precisely, it cannot be reproduced with the event whose address row is the first row in the table representing that address, according to whatever ordering the DBMS will use for a query without ORDER BY (typically ascending by primary key).
  • Do not make any changes and save

You should see an error immediately as you are redirected to the event page, something like

[2dfa5fa22d6f0a5ab08f2d24] /wiki/Event:T402239-2 RuntimeException: Events should have only one address.

Backtrace:

from /var/www/html/w/extensions/CampaignEvents/src/Address/AddressStore.php(210)
#0 /var/www/html/w/extensions/CampaignEvents/src/Event/Store/EventStore.php(185): MediaWiki\Extension\CampaignEvents\Address\AddressStore->getEventAddress()
#1 /var/www/html/w/extensions/CampaignEvents/src/Event/Store/EventStore.php(132): MediaWiki\Extension\CampaignEvents\Event\Store\EventStore->loadEventFromDB()
#2 /var/www/html/w/includes/libs/objectcache/WANObjectCache.php(1841): MediaWiki\Extension\CampaignEvents\Event\Store\EventStore->MediaWiki\Extension\CampaignEvents\Event\Store\{closure}()
#3 /var/www/html/w/includes/libs/objectcache/WANObjectCache.php(1646): Wikimedia\ObjectCache\WANObjectCache->fetchOrRegenerate()
#4 /var/www/html/w/extensions/CampaignEvents/src/Event/Store/EventStore.php(117): Wikimedia\ObjectCache\WANObjectCache->getWithSetCallback()
#5 /var/www/html/w/extensions/CampaignEvents/src/Event/PageEventLookup.php(62): MediaWiki\Extension\CampaignEvents\Event\Store\EventStore->getEventByPage()
#6 /var/www/html/w/extensions/CampaignEvents/src/EventPage/EventPageDecorator.php(164): MediaWiki\Extension\CampaignEvents\Event\PageEventLookup->getRegistrationForLocalPage()
#7 /var/www/html/w/extensions/CampaignEvents/src/Hooks/Handlers/ArticleViewHeaderHandler.php(46): MediaWiki\Extension\CampaignEvents\EventPage\EventPageDecorator->decoratePage()
#8 /var/www/html/w/includes/HookContainer/HookContainer.php(155): MediaWiki\Extension\CampaignEvents\Hooks\Handlers\ArticleViewHeaderHandler->onArticleViewHeader()
#9 /var/www/html/w/includes/HookContainer/HookRunner.php(917): MediaWiki\HookContainer\HookContainer->run()
#10 /var/www/html/w/includes/page/Article.php(706): MediaWiki\HookContainer\HookRunner->onArticleViewHeader()
#11 /var/www/html/w/includes/page/Article.php(549): MediaWiki\Page\Article->generateContentOutput()
#12 /var/www/html/w/includes/actions/ViewAction.php(84): MediaWiki\Page\Article->view()
#13 /var/www/html/w/includes/actions/ActionEntryPoint.php(728): MediaWiki\Actions\ViewAction->show()
#14 /var/www/html/w/includes/actions/ActionEntryPoint.php(505): MediaWiki\Actions\ActionEntryPoint->performAction()
#15 /var/www/html/w/includes/actions/ActionEntryPoint.php(143): MediaWiki\Actions\ActionEntryPoint->performRequest()
#16 /var/www/html/w/includes/MediaWikiEntryPoint.php(198): MediaWiki\Actions\ActionEntryPoint->execute()
#17 /var/www/html/w/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#18 {main}

This also happened a few times in production (example), it's easy to tell from the referrer being Special:EditEventRegistration.


Now for why it happens: when an event is updated, we take the new address and check if it already exists in the database. Crucially, this is done by comparing the address text itself: we do not keep track of address IDs associated with an event, partly because new events / new addresses do not have an ID. (The original plan, from when we started considering the geocoding epic, was to eventually switch to some other kind of unique identifier, e.g. provided by pelias).

However, after running the migration script, there can be multiple address rows representing the same address. This is possible if the two rows originally used two different (but equivalent) representations of the country, e.g. "Algeria" and "Algรฉrie". There was an AC in T397270 to clean these up as part of the migration script, but this was not implemented in the patch, along with the intention of creating a phab task for tracking that work. The task didn't come to be, so here we go.

The presence of equivalent address rows, together with the matching by text, results in the bug: suppose the two address rows have IDs 1 and 2, and the event is associated with address 2. If you make an edit, we will check if the event has a difference address associated, and this is obviously not the case. Then, in acquireAddressID, we will obtain the ID of the address row, but because this limits the search to one row, it will pick whatever row the DBMS puts first, which as I said, is typically the row with the lowest primary key, or row 1 in this case. It will then make an INSERT IGNORE with address 1, not realizing that address 2 was already there.

In short, the problem is that we are treating the full_address + country combination as a unique key, but it is currently not unique due to duplicates pre-dating the country code migration.


The fix is to finally add the code to clean up duplicated rows, then re-run the script on all databases. I'll make a patch now.

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

[mediawiki/extensions/CampaignEvents@master] Drop duplicated rows in UpdateCountriesColumn

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

Change #1179768 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Drop duplicated rows in UpdateCountriesColumn

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

Restricted Application added a subscriber: Daimona.

I will wait until the updates reach production (next week's train), then re-run the script to confirm there's nothing new. (moving to "dev in progress" for visibility)

This has happened again for https://meta.wikimedia.org/wiki/Special:EventDetails/1921, as the fix above still hasn't reached production.

wikiadmin2023@10.64.16.208(wikishared)> select * from ce_event_address group by ceea_event having count(*) > 1;
+---------+------------+--------------+
| ceea_id | ceea_event | ceea_address |
+---------+------------+--------------+
|    2474 |       1921 |          154 |
+---------+------------+--------------+
1 row in set (0.001 sec)

wikiadmin2023@10.64.16.208(wikishared)> select * from ce_event_address where ceea_event=1921;
+---------+------------+--------------+
| ceea_id | ceea_event | ceea_address |
+---------+------------+--------------+
|    2474 |       1921 |          154 |
|    2263 |       1921 |          210 |
+---------+------------+--------------+
2 rows in set (0.001 sec)

wikiadmin2023@10.64.16.208(wikishared)> select * from ce_address where cea_id in (154,210);
+--------+------------------+-------------+------------------+
| cea_id | cea_full_address | cea_country | cea_country_code |
+--------+------------------+-------------+------------------+
|    154 |                  | NULL        | NG               |
|    210 |                  | NULL        | NG               |
+--------+------------------+-------------+------------------+
2 rows in set (0.001 sec)

wikiadmin2023@10.64.16.208(wikishared)> select * from ce_event_address where ceea_address in (154,210);
+---------+------------+--------------+
| ceea_id | ceea_event | ceea_address |
+---------+------------+--------------+
|     333 |        225 |          154 |
|     646 |        437 |          210 |
|     652 |        442 |          210 |
|     758 |        521 |          210 |
|     938 |        628 |          210 |
|     981 |        629 |          210 |
|     979 |        631 |          210 |
|     986 |        636 |          210 |
|     942 |        638 |          210 |
|    1093 |        742 |          210 |
|    1180 |        783 |          210 |
|    1179 |        784 |          210 |
|    1181 |        786 |          210 |
|    1304 |        870 |          210 |
|    1317 |        894 |          210 |
|    1331 |        911 |          210 |
|    1365 |        936 |          210 |
|    1470 |       1033 |          210 |
|    1677 |       1246 |          210 |
|    1687 |       1258 |          210 |
|    1803 |       1400 |          210 |
|    1850 |       1432 |          210 |
|    1874 |       1449 |          210 |
|    1997 |       1591 |          210 |
|    1999 |       1593 |          210 |
|    2000 |       1595 |          210 |
|    2122 |       1754 |          210 |
|    2133 |       1766 |          210 |
|    2251 |       1916 |          210 |
|    2474 |       1921 |          154 |
|    2263 |       1921 |          210 |
|    2451 |       1938 |          154 |
|    2312 |       1949 |          210 |
|    2339 |       1966 |          210 |
|    2341 |       1967 |          210 |
|    2407 |       2024 |          154 |
|    2457 |       2070 |          154 |
+---------+------------+--------------+
37 rows in set (0.001 sec)

Proposed fix:

DELETE FROM ce_event_address WHERE ceea_id = 2474;
UPDATE ce_event_address SET ceea_address = 210 WHERE ceea_address = 154;
DELETE FROM ce_address WHERE cea_id = 154;

I'll run this soon in prod.

Mentioned in SAL (#wikimedia-operations) [2025-08-25T15:33:34Z] <Daimona> Running queries from T402239#11115333 in x1.wikishared to fix broken event addresses

Done:

wikiadmin2023@10.64.32.36(wikishared)> DELETE FROM ce_event_address WHERE ceea_id = 2474;
Query OK, 1 row affected (0.002 sec)

wikiadmin2023@10.64.32.36(wikishared)> UPDATE ce_event_address SET ceea_address = 210 WHERE ceea_address = 154;
Query OK, 4 rows affected (0.004 sec)
Rows matched: 4  Changed: 4  Warnings: 0

wikiadmin2023@10.64.32.36(wikishared)> DELETE FROM ce_address WHERE cea_id = 154;
Query OK, 1 row affected (0.002 sec)

I'll keep this task here until I can run the maintenance script to clean up the rest and prevent more breakage.

Aklapper renamed this task from RuntimeException: Event 1836 should have only one address. to RuntimeException: Event should have only one address..Aug 26 2025, 10:13 AM

Happened again with event 1979, and https://meta.wikimedia.org/wiki/Special:AllEvents is now also broken.

wikiadmin2023@10.64.0.214(wikishared)> select * from ce_event_address group by ceea_event having count(*) > 1;
+---------+------------+--------------+
| ceea_id | ceea_event | ceea_address |
+---------+------------+--------------+
|    2476 |       1979 |          122 |
+---------+------------+--------------+
1 row in set (0.002 sec)

wikiadmin2023@10.64.0.214(wikishared)> select * from ce_event_address where ceea_event = 1979;
+---------+------------+--------------+
| ceea_id | ceea_event | ceea_address |
+---------+------------+--------------+
|    2476 |       1979 |          122 |
|    2363 |       1979 |          195 |
+---------+------------+--------------+
2 rows in set (0.001 sec)

wikiadmin2023@10.64.0.214(wikishared)> select * from ce_address where cea_id in (122,195);
+--------+------------------+-------------+------------------+
| cea_id | cea_full_address | cea_country | cea_country_code |
+--------+------------------+-------------+------------------+
|    122 |                  | NULL        | BJ               |
|    195 |                  | NULL        | BJ               |
+--------+------------------+-------------+------------------+
2 rows in set (0.001 sec)

wikiadmin2023@10.64.0.214(wikishared)> select * from ce_event_address where ceea_address in (122,195);
+---------+------------+--------------+
| ceea_id | ceea_event | ceea_address |
+---------+------------+--------------+
|     267 |        178 |          122 |
|     452 |        277 |          195 |
|     480 |        315 |          195 |
|     814 |        552 |          195 |
|     996 |        679 |          195 |
|    1042 |        701 |          195 |
|    1077 |        730 |          195 |
|    1231 |        821 |          195 |
|    1520 |       1094 |          195 |
|    2025 |       1621 |          195 |
|    2054 |       1654 |          195 |
|    2114 |       1733 |          195 |
|    2476 |       1979 |          122 |
|    2363 |       1979 |          195 |
|    2453 |       2067 |          122 |
|    2456 |       2069 |          122 |
+---------+------------+--------------+
16 rows in set (0.001 sec)

Proposed fix:

DELETE FROM ce_event_address WHERE ceea_id = 2476;
UPDATE ce_event_address SET ceea_address = 195 WHERE ceea_address = 122;
DELETE FROM ce_address WHERE cea_id = 122;

Mentioned in SAL (#wikimedia-operations) [2025-08-26T11:55:58Z] <Daimona> Running queries from T402239#11118710 in x1.wikishared to fix broken event addresses (again)

Fixed:

wikiadmin2023@10.64.32.36(wikishared)> DELETE FROM ce_event_address WHERE ceea_id = 2476;
Query OK, 1 row affected (0.003 sec)

wikiadmin2023@10.64.32.36(wikishared)> UPDATE ce_event_address SET ceea_address = 195 WHERE ceea_address = 122;
Query OK, 3 rows affected (0.003 sec)
Rows matched: 3  Changed: 3  Warnings: 0

wikiadmin2023@10.64.32.36(wikishared)> DELETE FROM ce_address WHERE cea_id = 122;
Query OK, 1 row affected (0.002 sec)

And Special:AllEvents is back up. Hopefully this should stop happening soon once the patch reaches prod and I run the script. (Also worth noting, I'd rather not backport it if possible, because the patch above was dependent on various other patches that touched the script, so the backport wouldn't be straightforward)

Mentioned in SAL (#wikimedia-operations) [2025-08-28T14:01:23Z] <Daimona> mwscript-k8s --comment="T402239" -f -- CampaignEvents:UpdateCountriesColumn --wiki testwiki

Mentioned in SAL (#wikimedia-operations) [2025-08-28T14:04:39Z] <daimona@deploy1003> mwscript-k8s job started: CampaignEvents:UpdateCountriesColumn --wiki test2wiki --nowarn # T402239

Mentioned in SAL (#wikimedia-operations) [2025-08-28T14:06:19Z] <daimona@deploy1003> mwscript-k8s job started: CampaignEvents:UpdateCountriesColumn --wiki officewiki --nowarn # T402239

Mentioned in SAL (#wikimedia-operations) [2025-08-28T14:14:05Z] <daimona@deploy1003> mwscript-k8s job started: CampaignEvents:UpdateCountriesColumn --wiki metawiki --nowarn # T402239

I ran the script everywhere:

Worth noting that I didn't do a good job with the debug output, with unclear format, missing spaces and newlines, IDs repeated in the row desc, and rows being counted multiple times. Also, the script updated stuff with --dry-run when it wasn't supposed to. I'm going to fix these things before calling this task done, but production is now error-free.

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

[mediawiki/extensions/CampaignEvents@master] UpdateCountriesColumn: respect dry-run and improve output

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

Change #1182851 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] UpdateCountriesColumn: respect dry-run and improve output

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

Noting that following the directions for reproducing in T402239#11096488 the --commit flag did not work with the following line:

php maintenance/run.php CampaignEvents:UpdateCountriesColumn --commit

I have no name!@b495a70ffbdd:/var/www/html/w$ php maintenance/run.php CampaignEvents:UpdateCountriesColumn --commit

ERROR: Unexpected option --commit!


takes existing values from the cea_countries column and attempts to match then
with a country code

Usage: php maintenance/run.php CampaignEvents:UpdateCountriesColumn [OPTION]...

Script runner options:
    --conf <CONF>: Location of LocalSettings.php, if not default
 
... etc, etc, etc

and when I ran it without that --commit flag it said it had already been run

but then when I ran it with --force then it did update the rows:

========= 2 address rows updated ========
20 - "Algรฉrie" matched DZ (Algรฉrie)
21 - "Algeria" matched DZ (Algeria)
========= 0 unmatched address rows ========
========= 0 events without country made online =========
========= Dropped 1 duplicated rows =========

So, I am not sure if that is worth reporting or not @Daimona BUT I can confirm that it did correctly drop the duplicated row, and the second event created had no errors when saving on Special:EditEventRegisration (without changing anything). I ran this test three times, resetting the DB to MIGRATION_OLD before each test, and the results were the same. Though the second and third times I did not use the --commit flag, but did need to use --force to get it to make the migration, each time.

Here's the whole stack trace:

โžœ  CampaignEvents git:(master) docker-compose exec mediawiki bash
I have no name!@b495a70ffbdd:/var/www/html/w$ php maintenance/run.php CampaignEvents:UpdateCountriesColumn
...Update 'MediaWiki\Extension\CampaignEvents\Maintenance\UpdateCountriesColumn' already logged as completed. Use --force to run it again.
I have no name!@b495a70ffbdd:/var/www/html/w$ php maintenance/run.php CampaignEvents:UpdateCountriesColumn --force
Updating event country schema...
========= 0 events without address made online =========
The UpdateCountriesColumn script is about to update stored countries for all events. This is potentially DESTRUCTIVE, because countries that can't be mapped to a valid country code will be deleted, and the respective events will be changed to online. If you wish to take a closer look, abort with control-c in the next 15 seconds and run the script manually. (skip this countdown with --nowarn) ... 00
========= 0 purged address rows (unused) =========
========= 1 address rows updated ========
24 - "Algรฉrie" matched DZ (Algรฉrie)
========= 0 unmatched address rows ========
========= 0 events without country made online =========
========= Dropped 1 duplicated rows =========
20 ([no address] // DZ) has 1 copies: 24
I have no name!@b495a70ffbdd:/var/www/html/w$

If this is fine, then this ticket can be marked as completed, as everything is working correctly as long as I use the --force flag and also as long as I do not use the --commit flag

Noting that following the directions for reproducing in T402239#11096488 the --commit flag did not work with the following line:

Those instructions are outdated, as the flag in question has since been removed (for T401336). Now it's flipped like most other maintenance scripts, requiring explicit use of --dry-run not to make any changes (and the default being to make changes). Usage of --force is also expected now that the script is marked as a one-off migration.

The results you got are consistent with this and therefore correct, AFAICT.

vaughnwalters added a subscriber: ifried.

Noting that following the directions for reproducing in T402239#11096488 the --commit flag did not work with the following line:

Those instructions are outdated, as the flag in question has since been removed (for T401336). Now it's flipped like most other maintenance scripts, requiring explicit use of --dry-run not to make any changes (and the default being to make changes). Usage of --force is also expected now that the script is marked as a one-off migration.

The results you got are consistent with this and therefore correct, AFAICT.

Okay perfect. @ifried This is done and working as expected now, but thought I'd pass it to you for sign off / visibility since this issue presented a few times. And nice work tracking this down @Daimona !

Marking this done. Thank you for the work & testing on this, both of you!