wikiadmin2023@10.64.16.208(wikishared)> select event_id, event_deleted_at from campaign_events where event_page_title = 'Bicentenario_de_Bolivia';
+----------+------------------+
| event_id | event_deleted_at |
+----------+------------------+
|     1381 | 20250526160727   |
+----------+------------------+
1 row in set (0.003 sec)

So, data could be restored by running the following query:

UPDATE campaign_events SET event_deleted_at = NULL WHERE event_id = 1381

Mentioned in SAL (#wikimedia-operations) [2025-05-27T17:01:48Z] <jynus> restore row per request T395350

I've run that, but this needs followup.

Thank you! The event is now visible: https://meta.wikimedia.org/wiki/Special:EventDetails/1381

Oddly, there's no informational header on the event page, but maybe that's a caching thing; I'll take another look in a bit. I'm also investigating the bug that led to the deletion in T395351. I'll resolve this task as soon as the header comes back.

My wonder is if deletion does more stuff that just setting it as deleted. I am not familiar with the code base. Let's wait, but more steps could be needed for recovery.

In T395350#10860510, @Daimona wrote:

Oddly, there's no informational header on the event page, but maybe that's a caching thing

Ah yeah, that's the 1-week cache added in r1139200 / T392784. Since restoring events is technically not supported, the cache wasn't purged here. We could surely delete the key from WAN cache:

> $key = $wan->makeKey( 'CampaignEvents', 'EventStore', NS_EVENT, 'Bicentenario_de_Bolivia', false);
= "metawiki:CampaignEvents:EventStore:1728:Bicentenario_de_Bolivia:"

> $wan->get("metawiki:CampaignEvents:EventStore:1728:Bicentenario_de_Bolivia:");
= MediaWiki\Extension\CampaignEvents\Event\ExistingEventRegistration {#7648}

but making a dummy edit to the event registration should also update the cache, so I've asked the organizer to do that.

In T395350#10860532, @jcrespo wrote:

My wonder is if deletion does more stuff that just setting it as deleted. I am not familiar with the code base. Let's wait, but more steps could be needed for recovery.

It might do some extra updates, but that's mostly only relevant when the P&E Dashboard is used for that event. In this case, it's just some caches that get purged or, in this case, remain stale.

In T395351 I tried reproducing this bug locally but couldn't. As noted in T395351#10860985 though, the deletion timestamp in T395350#10860354 is inaccurate. Would it be possible to scan the binlogs from yesterday (May 26th) and find the timestamps of all queries like UPDATE campaign_events [...] SET event_deleted_at [...] WHERE [...] event_id = 1381 on db1237? I'm not sure if I have permission to do that.

Edit: the exact query (modulo formatting and quotes) should be UPDATE campaign_events SET event_deleted_at = <timestamp I'm interested in> WHERE event_id = 1381 AND event_deleted_at IS NULL.

There should be at least one of these, but most likely a few of them. I'm interested in the timestamp of the earliest such query.

From 2 days ago until now, I only see 2 deletion events, 1727 at 14:26:20 and 1381, at 16:07:27 (all times are UTC).

$ mysqlbinlog --database="wikishared" db1225-bin.003651 db1225-bin.003652 db1225-bin.003653 db1225-bin.003654 db1225-bin.003655 db1225-bin.003656 db1225-bin.003657 db1225-bin.003658 db1225-bin.003659 db1225-bin.003660 db1225-bin.003661 db1225-bin.003662 db1225-bin.003663 db1225-bin.003664 db1225-bin.003665 db1225-bin.003666 db1225-bin.003667 db1225-bin.003668 db1225-bin.003669 db1225-bin.003670  | grep -B1 "deleteRegistration"
#250526 14:44:17 server id 171966678  end_log_pos 950146829 CRC32 0xda3194cb    Annotate_rows:
#Q> UPDATE /* MediaWiki\Extension\CampaignEvents\Event\Store\EventStore::deleteRegistration  */  `campaign_events` SET event_deleted_at = '20250526144417' WHERE event_id = 1727 AND event_deleted_at IS NULL
--
#250526 16:07:27 server id 171966678  end_log_pos 1016902351 CRC32 0x11646464   Annotate_rows:
#Q> UPDATE /* MediaWiki\Extension\CampaignEvents\Event\Store\EventStore::deleteRegistration  */  `campaign_events` SET event_deleted_at = '20250526160727' WHERE event_id = 1381 AND event_deleted_at IS NULL

The latter:

{P76556}

I double confirmed that the timestamp @ 16:07:27 is accurate to the second on the primary db.

Edit: Just to be extremely redundant: the update happened on the primary db server at 16:07:27 and it wrote the string timestamp '20250526160727'. This data also matches the state of the db after backup, taken at 0 hours on the 27th, meaning it kept that info until manual nullification at 2025-05-27 17:01:57.