Notes backend QuickStatements batches seems broken for this reason.

Maxlag now climbed to 300+ days again: https://grafana.wikimedia.org/d/000000170/wikidata-edits?orgId=1&from=1589485983686&to=1589486256637

This breaks Widars too as Widar sleeps 3*maxlag+1 seconds before edits, and now Widar sleeps 919 days.

@Gehel and @Zbyszko any idea what's causing these huge spikes? Work on the server? Something else?

Looking at WDQS lag and [[ URL | Wikidata lag ]] in parallel, I don't see a clear correlation between the 2. There have been a few data reloads last week (you can see the spike on lag on the WDQS side), but the servers should be depooled during that operation. And the spike on lag is only 2h.

It looks like the Wikidata lag is always at 43.80 weeks. This looks like a NaN converted to something wrong, or an overflow of some kind.

@Addshore: you might have a better idea of what's could be happening on the Wikidata side.

Side note: exposing both the MySQL replication lag and the WDQS replication lag through the same value seems like a bit of an abuse of the system. Would it be better to expose both separately and let the clients have a more specific interpretation of those numbers?

The number of second was current Unix time/60, which means unavailable server are treated as have a epoch of zero.

I guess this is partly T252077

Hi @Bugreporter, I just saw your report. Thank you for making us aware of this! It appears to me as if this issue has been solved. Can you confirm this?

This may be relied on T238751: Only generate maxlag from pooled query service servers..