The schema change made in T387488 was applied in production (T394509) before the patch that updates the code actually landed. So, the old code was trying to insert event_type whereas the column no longer existed in the schema. This resulted in 78 logged instances where enabling registration failed. The outage started when the schema change was applied (2025-05-19 ~05:00 UTC) and ended with the roll-out of wmf.2 (T392172): 2025-05-21 ~08:03 UTC for group 1, and 2025-05-22 ~08:20 UTC for group2, which matches the timeline above.

These did not show up as observable failure modes, but also worth noting:

• The code that writes to the new column was added in the same wmf.2 version. So, even performing the schema change after the train roll-out would have resulted in outages due to the new column (event_types) not existing, instead of the old one. Such an outage would've lasted from the roll-out to the schema change, but it would have been much less manageable in case of train rollbacks.
• Even without writing the new columns, the schema change patch was not compatible, because it stopped writing to the event_type column, which is NOT NULL and has no default. So, there still would've been an outage in that case.

For posterity: there are a few options as to how this could've been done without breaking anything. "Serious" schema changes (involving large tables, lots of data, and where the old data is valuable or a maintenance script is needed to change stuff) would use a config setting and the MIGRATION_* constants. Here, given the size of the tables involved, the fact that the old data can be discarded, and the fact that the new column has a default, we could use a simplified process.

Option 1: two schema changes

• Make a first schema change that only adds a default to the old column, leaving the code unchanged
• Wait for the code to reach production (can be backported), apply the change
• Then make a schema change that drops the old column, adds the new one, and stops writing to the old column (but does not write to the new one).
• Wait for the code to reach production (can be backported), apply the change. Note, no breakage here because the default value added in the first step is used.
• Make a final patch to write to the new column

Option 2: feature flag

• Make a schema change patch that drops the old column and adds the new one. In the code, add a feature flag, and have it control whether the old or the new column is written. By default, write to the old column.
• Wait for the code to reach production (can be backported)
• Prepare a config patch that flips the feature flag (write to the new column)
• Coordinate with a deployer and a DBA so that the schema change is applied, and the config patch is deployed immediately afterwards (does not fully avoid outages, but limits them to a short window with a good chance of no impacted users)
• Clean up everything feature flag-related

At any rate, the issue has been resolved, so I'm closing this task.