Following <https://gerrit.wikimedia.org/r/442198> (per T195314#4317397), I'm trying to see whether Navigation Timing reports have increased in Beta. But it seems they remain at zero. Given the sample rate of 1/10, I figured I'd just try locally a few times to click on the main page, and eventually got sampled, but noticed the following error in the console.
```counterexample,name=Console
[NavigationTiming] Missing or empty schema
```
Looking at the network fetch for the schemas from load.php, it got the following:
<https://en.wikipedia.beta.wmflabs.org/w/load.php?debug=false&lang=en&modules=schema.NavigationTiming|schema.SaveTiming>
```lines=3,lang=js,name=load.php
mw.loader.implement("schema.NavigationTiming@02ba1tn", function($, jQuery, require, module) {
mediaWiki.eventLog.declareSchema("NavigationTiming", {
"schema": {},
"revision": 18156125
});
});
mw.loader.implement("schema.SaveTiming@10h98u7", function($, jQuery, require, module) {
mediaWiki.eventLog.declareSchema("SaveTiming", {
"schema": {
"title": "SaveTiming",
"properties": {
"saveTiming": {
[..]
```
Given it only affects the NavigationTiming schema, and not the SaveTiming schema in the same request, I suspected a recent change (maybe <https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/NavigationTiming/+/441934/>, which changed the revision ID). However, I that didn't seem to be the cause because:
1. NavigationTiming was working fine on my localhost MediaWiki.
2. And, the underlying API request that EventLogging makes from load.php works fine (<https://meta.wikimedia.org/w/api.php?action=jsonschema&revid=18156125&formatversion=2>).
That request is triggered from EventLogging/RemoteSchema.php ([source code](https://github.com/wikimedia/mediawiki-extensions-EventLogging/blob/ea95faf83691/includes/RemoteSchema.php#L42-L105)). Which does the following:
* get:1: Try memcGet() = false (key doesn't exist).
* get:2: Try httpGet()
** httpGet:1: Acquire cache->lock(), or return false.
** httpGet:2: Fetch schema from meta.wikimedia.org over HTTP.
** httpGet:3: Parse response as JSON.
** httpGet:4: If fetch or parsing failed, log error and return false.
** httpGet:5: Return parsed response.
There are no log messages about the request failing. And as mentioned, trying that request manually shows it works fine. Instead, what I find when trying to reproduce it via the REPL, is that it seems Memcached isn't allowing PHP to acquire a lock.
When manually calling `$cache->get()` with the lock key, it returns false suggesting the lock isn't taken. Yet, when calling `$cache->add()` with the lock key, it also returns false.
If this is due to the mcrouter configuration using the MultiWrite/ReplicatedBagOStuff logic, then it might be the same root-cause as T198279.
See also:
* {a9124c2f5867671a76c1700cdbc76fc2b3e5cb61}