Heads-up that there's a new extension on the release branch tool, IP Info. Not plugged into anything in config, nothing special, shouldn't be an issue, but please shout at me / @Tchanders if it breaks something. :-)

I have rolled 1.36.0-wmf.20 on all wikis over the last hour. There was an issue with ParserOutput serialization but that has been rolled back from the code both in the wmf branch and the master branch, so 1.36.0-wmf.21 should be fine. The plan is to wait for the parser cache entries to dry out before switching entirely to json serialization.

Change 646887 had a related patch set uploaded (by DannyS712; owner: trainbranchbot):
[mediawiki/core@wmf/1.36.0-wmf.21] Branch commit for wmf/1.36.0-wmf.21

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

I've filed T269650: InvalidArgumentException on Special:EntityData for existing senses, T269651: InvalidArgumentException on zhwiki MediaWiki:Conversiontable/zh-hk - "The supplied ParserOptions are not safe to cache. Use NO_CACHE.", and T269652: RuntimeException in ApiCentralNoticeQueryCampaign - should any be a train blocker for this week, and/or prompt a revert of wmf.20 which was only rolled out yesterday/today (depending on your timezone)?

Change 646887 merged by jenkins-bot:
[mediawiki/core@wmf/1.36.0-wmf.21] Branch commit for wmf/1.36.0-wmf.21

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

In T264801#6675430, @DannyS712 wrote:

I've filed T269650: InvalidArgumentException on Special:EntityData for existing senses, T269651: InvalidArgumentException on zhwiki MediaWiki:Conversiontable/zh-hk - "The supplied ParserOptions are not safe to cache. Use NO_CACHE.", and T269652: RuntimeException in ApiCentralNoticeQueryCampaign - should any be a train blocker for this week, and/or prompt a revert of wmf.20 which was only rolled out yesterday/today (depending on your timezone)?

The first one is not new in wmf.21, see T269603: InvalidArgumentException when requesting Special:EntityData with Sense or Form ID (The given ID does not refer to an entity of type lexeme).

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/647081 - is fixing T269727, which is pretty bad. It will only affect group0 cause we only have old revision caching enabled there, but I would recommend we back port it still.

Mentioned in SAL (#wikimedia-operations) [2020-12-09T20:18:10Z] <twentyafterfour> wmf.21 looks good on group1 wikis. Still seeing T269603 but not at an increased rate. (refs T264801)

Not sure if it’s serious enough to be a train blocker but this seems to be a visual regression in wmf.21: T269801

Mentioned in SAL (#wikimedia-operations) [2020-12-10T22:32:31Z] <twentyafterfour@deploy1001> Synchronized php-1.36.0-wmf.21/resources/lib/ooui/oojs-ui-widgets-wikimediaui.css: sync https://gerrit.wikimedia.org/r/c/mediawiki/core/+/647641 to fix T269477 and unblock T264801 (duration: 01m 04s)

In T264801#6675430, @DannyS712 wrote:

I've filed T269650: InvalidArgumentException on Special:EntityData for existing senses, T269651: InvalidArgumentException on zhwiki MediaWiki:Conversiontable/zh-hk - "The supplied ParserOptions are not safe to cache. Use NO_CACHE.", and T269652: RuntimeException in ApiCentralNoticeQueryCampaign - should any be a train blocker for this week, and/or prompt a revert of wmf.20 which was only rolled out yesterday/today (depending on your timezone)?

Hi @DannyS712 ! Thanks for finding that CentralNotice bug. We've got a patch ready for it, but I wouldn't consider it a train blocker. It's a sanitization failure, but one that doesn't expose us to any harm outside of those error log entries - the parameter is used in a query which is properly performed using DB wrapper functions. We'd prefer to put the fix out with some other accumulated CN patches after the year-end fundraiser.

In T264801#6689605, @Ejegg wrote:

We'd prefer to put the fix out with some other accumulated CN patches after the year-end fundraiser.

Just adding to @Ejegg's comment... AFIK, at this time, that API is rarely used, if at all, and there were just 16 of these errors on production in the last month (logstash).