Oh, sorry I didn't quickly realized that you already removed then. I overlooked anything that started with "regen_...".

Had to run this multiple times before everything got renamed. But it's done now.

Done!

@stevenwalling, thanks for reporting.

Treated! Thanks 🙏🏽

@MGChecker, reopen in case you think this needs more action. Thanks!

These updates all look good to me. Tried to search our mw{dot}org for references to see if I find anything using the previous default, but didn't find any. Everything looks fine to me.

@DreamRimmer, I think this should be done now. Please could you confirm on your end and resolve the task? Thank you :)

This will wait a little for T363699: Determine and implement SUL 3 login handshake mechanism to be completed before continuing.

@MGChecker, I dig some digging and found the following:

In T123792#7250442, @Raphoraph wrote:

Hi, I've documented some configuration parameters in CentralAuth: https://www.mediawiki.org/wiki/Extension:CentralAuth#Configuration, see the last three entries.
I'm kindly asking to have someone check it, for typos and also to be sure I didn't get the examples/the way it works wrong.

In T370636#10004873, @Krinkle wrote:

Derick raise a good question: Why did this bug cause the timeseries to stop, rather than e.g. continuing with "wrong" data?

Documented at https://wikitech.wikimedia.org/wiki/Graphite#Extended_properties, counters and timers have various extended properties so a counter metric like MediaWiki.foo.bar is generally accessed as MediaWiki.foo.bar.rate or .sum, timers would also have .p75 etc. There are a few properties that both counters and gauges get, but e.g. .p75 is specific to timers, .rate is specific to counters, etc. Unlike counters and timers, gauges actually have something they can store under their canonical name, so MediaWiki.foo.bar as Gauge would actually exist as metric Graphite even without an extended property.

As such, when you plot a gauge and accidentally change it to a counter, there's a good chance the underlying extended property will not receive any more data.

In Codesearch, we found exactly one other maintenance script sending gauges to Statsd: MediaWiki's getLagTimes.php. This was converted in T359382 (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1026901) but did not break the graph at https://grafana.wikimedia.org/d/G9kbQdRVz/mediawiki-loadbalancer?orgId=1. That's because that graph renders .mean and that just so happens to exist both for gauges (the mean of the stored values in the current resolution window), and for counters (the mean increment, increments are usually +1, so the mean of a counter is usually a flat line at 1). But in this case it was happily storing lag times as counters, and the .mean is plausible/close enough to what the gauge would look like.

[quick update] This is picking back up again: https://grafana.wikimedia.org/d/BvWJlaDWk/startup-manifest-size?orgId=1&var-wiki=testwiki&var-component=All&from=now-2d&to=now&var-multiwiki=testwiki. Did a quick look yesterday and I can already see some data points from testwiki.

This is now resolved. The rest of the work is going to happen on the parent task.

This looks like it's called multiple times (2x as far as I can see) in practice. In ClientHtml::getHeadHtml() and ClientHtml::getBodyHtml(), and in both calls, it does the same computation.

There is a pending decision to be made on the patch re PerDbNameStatsDataFactory vs just prefixing the metric name with MainConfigNames::DBname. Once there is a decision to move forward, then we can resume on this. :)

Done! Can test using: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Main+Page&usesul3=1

I'm able to reproduce this locally with RestMan (browser extension for simulating CORS request).

Looks like we can resolve this. Thanks @Tgr! 💥

This doesn't happen frequently but not exactly sure what could be the course of it.