Presumably harmless inasmuch as code like:

<?php

$namespaceNames = [];

$namespaceNames['en'] = [
        NS_LQT_THREAD       => 'Thread',
        NS_LQT_THREAD_TALK  => 'Thread_talk',
        NS_LQT_SUMMARY      => 'Summary',
        NS_LQT_SUMMARY_TALK => 'Summary_talk',
];

...will just fall back to the literal constant name, as per usual, looks like we get this logspam routinely while deploying and I just haven't noticed it lately:

Caused by 7bace0bdf0d269a3302a84b11037150e992ac710

CC @thiemowmde

In T256151#6249569, @brennen wrote:

Presumably harmless inasmuch as code like:

<?php

$namespaceNames = [];
$namespaceNames['en'] = [
        NS_LQT_THREAD       => 'Thread',
        NS_LQT_THREAD_TALK  => 'Thread_talk',
        NS_LQT_SUMMARY      => 'Summary',
        NS_LQT_SUMMARY_TALK => 'Summary_talk',
];

This is not harmless. The string NS_LQT_THREAD does not equal int(90) which is what it is meant to hold, so whatever will read these will not find them and thus cause other errors or corruption elsewhere in production later on when other proceses read the localisation cache.

Any artefact created by a process with these warnings should be deleted and re-created as soon as possible.

Change 607372 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/extensions/LiquidThreads@master] Use intended integer values for keys to $namespaceNames

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

Change 607373 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/extensions/LiquidThreads@master] Define NS_LQT in Lqt.namespaces.php

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

Change 607372 abandoned by DannyS712:
Use intended integer values for keys to $namespaceNames

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

Change 607379 had a related patch set uploaded (by Krinkle; owner: Reedy):
[mediawiki/extensions/LiquidThreads@wmf/1.35.0-wmf.37] Define NS_LQT in Lqt.namespaces.php

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

Change 607380 had a related patch set uploaded (by Krinkle; owner: Reedy):
[mediawiki/extensions/LiquidThreads@wmf/1.35.0-wmf.38] Define NS_LQT in Lqt.namespaces.php

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

Change 607373 merged by jenkins-bot:
[mediawiki/extensions/LiquidThreads@master] Define NS_LQT in Lqt.namespaces.php

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

Per IRC discussion with @Krinkle: This appears to have broken the _old_ deploy on Tuesday train deploys since late March:

Krinkle │ that suggests LQT was fine until yesterday and that it is also fine on the newly generated wmf.38
Krinkle │ it seems to always corrupt the older version on Tuesday
Krinkle │ I guess that's because the older version is "randomly" always cawikibooks, which doesn't have LQT
Krinkle │ and the newer version is "randomly" a group0 wwiki that does have LQT

It's not _totally_ clear why those errors weren't caught at the time, but it's likely because they happen during the l10n rebuild on the original sync to testwikis, while deployers are mostly focused on the deploy operation itself, rather than later once new code is promoted to group0 and is getting traffic. That they show up in the previous train's code rather than the current one is also a likely factor.

I intend to do a full scap sync with backports merged at local start-of-day tomorrow. This remains a train blocker in the sense that it needs fixing before we proceed, although it's not exactly new breakage with wmf.38.

Mentioned in SAL (#wikimedia-operations) [2020-06-24T15:06:09Z] <brennen> merging backports and running a full scap sync for UBN at T256151

Change 607379 merged by jenkins-bot:
[mediawiki/extensions/LiquidThreads@wmf/1.35.0-wmf.37] Define NS_LQT in Lqt.namespaces.php

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

Change 607380 merged by jenkins-bot:
[mediawiki/extensions/LiquidThreads@wmf/1.35.0-wmf.38] Define NS_LQT in Lqt.namespaces.php

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

Mentioned in SAL (#wikimedia-operations) [2020-06-24T15:38:32Z] <brennen> previous scap sync for T256151 - [[gerrit:607379]] and [[gerrit:607380]]