Stable on all wikis.
Details
- Backup Train Conductor
- • LarsWirzenius
- Release Version
- 1.37.0-wmf.4
- Release Date
- May 3 2021, 12:00 AM
2021 week 18 1.37-wmf.4 Changes wmf/1.37.0-wmf.4
This MediaWiki Train Deployment is scheduled for the week of Monday, May 3rd:
Monday May 3rd | Tuesday, May 4th | Wednesday, May 5th | Thursday, May 6th | Friday |
---|---|---|---|---|
Backports only. | Branch wmf.4 and deploy to Group 0 Wikis. | Deploy wmf.4 to Group 1 Wikis. | Deploy wmf.4 to all Wikis. | No deployments on fridays |
- See https://wikitech.wikimedia.org/wiki/Deployments for full schedule.
How this works
- Any serious bugs affecting wmf.4 should be added as subtasks beneath this one.
- Use this form to create one.
- Any open subtask(s) block the train from moving forward. This means no further deployments until the blockers are resolved.
- If something is serious enough to warrant a rollback then you should bring it to the attention of deployers on the #wikimedia-operations IRC channel.
- If you have a risky change in this week's train add a comment to this task using the Risky patch template
- For more info about deployment blockers, see Holding the train.
Related Links
- Train status
- MediaWiki 1.37/Roadmap
- Commits cherry-picked to 1.37.0-wmf.4
- Backports vs train deployment
Other Deployments
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Release | brennen | T281145 1.37.0-wmf.4 deployment blockers | ||
Resolved | BUG REPORT | hoo | T281450 Exception: Table 'enwiki.wb_items_per_site' doesn't exist | ||
Duplicate | None | T282193 Query time out in ApiQueryLogEvents query | |||
Resolved | PRODUCTION ERROR | tstarling | T282038 PHP Deprecated: Caller from LinkBatch::doQuery (for Skin::preloadExistence) ignored an error originally raised from SpecialRecentChanges::doMainQuery: [1054] Unknown column 'actor_user' in 'on clause' (10.64.0.44) | ||
Resolved | tstarling | T282122 Frequent 504s while using logevents API on Commons | |||
Resolved | daniel | T282070 After unblocking autoblock, Special:Log and Special:RecentChanges gives ParameterAssertionException: Bad value for parameter $dbKey | |||
Open | None | T282088 Create a way to consistently validate titles (dbKeys) for use in the database. | |||
Resolved | PRODUCTION ERROR | daniel | T282180 Special:Log/move: ParameterTypeException: Bad value for parameter $link: must be a MediaWiki\Linker\LinkTarget|MediaWiki\Page\PageReference |
Event Timeline
Assigning to @dancy for coverage while I'm out on the 4th; will pick back up as primary after that.
Not very, but notably risky patch! 🚂🔥
- Change: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/682328
- What it does/What it's risky:
- All title-related type expectations of Parser changed. Should all be entirely b/c, but we all know there's a lot of edge-cases in parser.
- Places to Watch for Breakage
- Logstash MediaWiki Errors Dashboard: https://logstash.wikimedia.org/app/kibana#/dashboard/mediawiki-errors
- Revert Plan: rollback
- Wikis Affected: all of them
- IRC Contact: @Pchelolo or @duesen (@daniel)
- UBN Task Projects/tags: Platform Engineering Platform Team Workboards (MW Expedition)
Risky Patch! 🚂🔥
- Changes:
- https://gerrit.wikimedia.org/r/c/mediawiki/core/+/678414 (removing hooks with Revision objects)
- https://gerrit.wikimedia.org/r/c/mediawiki/core/+/681379 (removing a couple random uses of methods using Revision, as well as EditPage::$mBaseRevision and Article::$mRevision)
- https://gerrit.wikimedia.org/r/c/mediawiki/core/+/681381 (remove PageArchive methods using Revision)
- https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/681377 (stop running core hook that uses Revision)
- What it does/What it's risky:
- There's nothing particularly risky about this one, but it's big and touching a lot of code. Specifically, we are starting the process of removing the Revision class and associated code, all of which was previously hard deprecated and should not have been executed in production.
- Test Plan:
- This should have all been dead code, with the deprecated hooks only run if any hook handlers were registered, and the rest directly emitting deprecation warnings, so there isn't really anything to test, just watching the logs
- Places to Watch for Breakage
- Logstash MediaWiki Errors Dashboard: https://logstash.wikimedia.org/app/kibana#/dashboard/mediawiki-errors
- Grafana Production Logging Dashboard: https://grafana.wikimedia.org/d/000000102/production-logging
- Revert Plan: rollback
- Wikis Affected: all
- IRC Contact: @DannyS712 (or @Pchelolo if I'm not around)
- UBN Task Projects/tags: User-DannyS712 (Platform Engineering if I'm not around)
Mentioned in SAL (#wikimedia-operations) [2021-05-04T17:02:59Z] <brennen> 1.37.0-wmf.4 was branched at f069fd8b5a6c817f4860fa68ae2f56b71a139f4a for T281145
1.37.0-wmf.4 has been on group0 for several hours. No apparent errors. Train looks good.
I'm going to mention here T281981: Special:RecentChanges with userExpLevel=newcomer causes Fatal exception of type "Wikimedia\Rdbms\DBQueryError": Unknown column 'actor_user' that seems to be happening since this deploy
Mentioned in SAL (#wikimedia-operations) [2021-05-05T19:01:21Z] <brennen> 1.37.0-wmf.4 train status (T281145): deploying patch for T282038 and then rolling forward to group1.
Note the client side errors for T262470 are spiking today and potentially could meet the train rollback criteria tomorrow. When rolling the train out tomorrow we should keep an eye on logstash for any huge client error spikes relating to that. cc @egardner for someone who actually knows this code and can speak for any possible impact.
Chatted to @egardner and the above error is likely limited to commons so not likely to be an issue tomorrow.
The "missing mediainfo tabs" error can only come from WikibaseMediaInfo, which is only deployed on Commons and is only active on File pages there. Why is it spiking now when the relevant code has not been touched in some time? That's another question.
Mentioned in SAL (#wikimedia-operations) [2021-05-07T18:23:45Z] <brennen> 1.37.0-wmf.4 train status (T281145): blockers appear resolved, going ahead in the interest of not having a split deploy over weekend