In T416616#11616527, @Krinkle wrote:

[…] Grafana: ParserCache dashboard:

According to a list curated by Lea Verou (W3C and CSSWG member) at https://github.com/LeaVerou/dpi/blob/gh-pages/devices.json via https://dpi.lv/, only 5 device models were known to have 1.5x screens:

MathJax SVG (status quo): OK

Current rendering on https://www.mediawiki.org/wiki/Extension:Math/Native_MathML/Reported_Cases

I don't know if the relation can be expressed natively in MathML, but at least right now but MediaWiki MathML rendering and the MathJax rendering use the same approach of setting the height manually on these parenthesis. And the MediaWiki one is indeed not tall enough cover the height of the expression.

Discouraging 1.5x in new code per T246054: Consider dropping the '1.5x' size logos from srcsets.

Before

For tasks about any Wikimedia-hosted repo where continuous integration tests fail.

I've clarified the intro of ci-test-error (WMF-deployed Build Failure), and added a note with an example.

Right now userCanSeeSecret denies anyone from seeing the secret (except once during creation). According to @Tgr this is similar to other platforms, which don't let you see it later either. There's not a strong reason to disallow access to it, so this is a production question, about use case and potential risk trade-off. Punting to @JTweed-WMF to decide next week.

Thank you for tagging this task with good first task for Wikimedia newcomers!

In T200629#11589795, @Umherirrender wrote:

The use of static closures (T274038: Enforce use of static closures) in mediawiki codestyle could be an suprise as well […]

If I understand correctly, the data-values/value-view repo is not used as Composer package via mediawiki/vendor, and also not extracted from or embedded in the Wikibase extension repo, but rather is purely used in production via a git submodule reference.

I added the "Excluded files" view in April 2024 to make these kinds of things inspectable.

The API is part of upstream Hound: https://github.com/hound-search/hound

Both the Hound frontend and our own frontend use client-side JavaScript to render and highlight intraline matches in the results, which requires the pattern to be a valid RegExp in JavaScript.

It looks like the Hound backend does support this, although the default Hound frontend does not. So our frontend currently behaves the same.

The limitation is not 20 in total, but 20 per repo. The same data is used for both the the "Default" and "Phabricator" result formats.

Thank you for tagging this task with good first task for Wikimedia newcomers!

The downside is that this will index the master branch of VisualEditor core and not the version currently deployed via the submodule reference of mediawiki/extensions/VisualEditor.

In T413739#11498877, @Dzahn wrote:

weird file names though. maybe the logrotate config had a problem? I think we can just keep it off though.

In T417397#11616797, @Krinkle wrote:

Ah, the curse of inodes again. This time on the root drive instead of the /srv volume.

Grafana dashboard:

In T417397#11616797, @Krinkle wrote:

Ah, the curse of inodes again. This time on the root drive instead of the /srv volume.

Grafana dashboard:

Ah, the curse of inodes again. This time on the root drive instead of the /srv volume.

The last errors in syslog are caused by my kills, but prior to that, the following stands out:

$ sudo tail -n10000 /var/log/syslog | grep -E 'hound|git|fatal|error'
…
2026-02-13T20:58:30+00:00 codesearch9 dockerd[630]: time="2026-02-13T20:58:30.582761078Z" level=error msg="Handler for POST /v1.41/containers/create returned error: mkdir /var/lib/docker/overlay2/42a40e41de17ec4242d62c3ce60b1b670346c189dbe855e254c0640581069dce-init/diff: no space left on device"
2026-02-13T20:58:30+00:00 codesearch9 systemd[1]: hound-core.service: Main process exited, code=exited, status=125/n/a
2026-02-13T20:58:30+00:00 codesearch9 systemd[1]: hound-core.service: Failed with result 'exit-code'.
2026-02-13T20:58:30+00:00 codesearch9 docker[1091236]: Error response from daemon: Cannot kill container: hound-skins: No such container: hound-skins
2026-02-13T20:58:30+00:00 codesearch9 docker[1091225]: Error: No such container: hound-services
2026-02-13T20:58:30+00:00 codesearch9 dockerd[630]: time="2026-02-13T20:58:30.626858965Z" level=error msg="Handler for POST /v1.41/containers/create returned error: mkdir /var/lib/docker/overlay2/307c526a7c37f326a1206c57a139ff4c27fdc599b291cd7cd0f6cbb20d2f7148-init/diff: no space left on device"
2026-02-13T20:58:30+00:00 codesearch9 systemd[1]: hound-operations.service: Main process exited, code=exited, status=125/n/a
2026-02-13T20:58:30+00:00 codesearch9 systemd[1]: hound-operations.service: Failed with result 'exit-code'.
2026-02-13T20:58:30+00:00 codesearch9 systemd[1]: hound-core.service: Scheduled restart job, restart counter is at 5.

Do we know why this became a problem recently?

I've solved this as part of T407122: [5.2.5 Milestone] Introduce API Gateway access controls on sitemap endpoints, by implementing the sitemap restriction as an HTTP 4xx error and applying a better error template there in general (as opposed to just for sitemaps or just for one error code).

For a lot of HTTP links in the database, the website is not dead. These fall in two categories:

In T414805#11612140, @gerritbot wrote:

[mediawiki/extensions/WikiEditor@master] Set background-size for toolbar buttons

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

One solution might be to accept the latency hit and always use Special:Filepath (Special:Redirect/file) in this JavaScript function.

Yes, the above suggestion from me can be implemented. I'll move back to our inbox so we can decide who/where in MwEng.

In T416540#11592285, @Jgiannelos wrote:

This diagram might also be interesting:
https://grafana.wikimedia.org/goto/Aqf_YrHvg?orgId=1

From what I understand, it looks like the sampled requests for profiling (thus the number of requests) for article views increased around the time we see the increase in latency. This means that we get more requests bypassing caches. […]

In T416171#11599749, @Ladsgroup wrote:

I had the worry that in cases that a user edits and adds or removes links, we wouldn't be able to reflect that because it's just after the edit and this lookup is happening in the context of deferred update (=right after main transaction has been committed on master) BUT the thing is that the lookup is for existing values and not the new ones (those come from the parser output object). So this shouldn't cause any regression because of deferred updates being too close to the main transaction.