We decided not to do this at the moment and to write down the reasons in an ADR (see T399574).

Yes, the "Total" numbers in the Legend were off, because of the way Grafana creates "rate" graphs (clicks per $interval) with one data point every 10mins or every half hour. Those numbers simply don't correctly add up to a "Total" number of clicks. I now tried to fix this by setting the minstep to $interval, which means we will only see one data point per selected interval. However, the "Total" numbers still differ, depending on the interval, which is not quite expected from a user's point of view. I'm also not convinced this is the intened way of displaying Prometheus's "Counter" metrics. Instead, I imagine it is much more useful to go with minimum steps of a few minutes (which will be calculated as the increase between counter[now] and counter[now - $interval]). This way it is probably best to display an average or median of the "clicks per $interval" in the legend. For now I added both, so that we can compare which one we like better.

I added two new panels on top of the two old ones in the "Button Clicks (Prometheus)" row. Data in the old panels can be viewed up until 2024-12-04, for comparison. Data in the new panels is shown from 2025-06-16. The old panels can probably be removed, once we decide that button click metrics of 2024 are no longer interesting.

In T394014#10887086, @Ollie.Shotton_WMDE wrote:

I believe Elasticsearch supports searching for Entities via their URL as well as their ID - might be worth checking if the SQL Based Searches also support that.

ElasticSearch / OpenSearch features are described in detail on https://www.mediawiki.org/wiki/Help:CirrusSearch and https://www.mediawiki.org/wiki/Help:Extension:WikibaseCirrusSearch, therefore I am limiting this to a description of the SQL based search features:

In T386691#10829160, @hashar wrote:

Why? I do not know :-] Maybe I can add a job that has opensearch enabled and make it non voting (ie if it fails, that would not vote Verified-1/block).

\o/

In T386691#10821895, @hashar wrote:

We will see how the mediawiki-quibble-apitests-vendor-php81 job behaves :]

True, the deployment had not actually happened when P13551 was created and blocked. For P13552 we do not see any 500 errors in the logs, but it is not quite clear if that's because the fix was working by that time already.

In T374230#10772794, @ArthurPSmith wrote:

Does the fix you have implemented align with that pattern?

Until then: as noted above, the problem is not actually caused simply by creating a new (Item or Lexeme type) Property - it only occurs when using that same Property in a statement on itself (e.g. via P1855) shortly after its creation. So if people should be warned, it would have to be about creating statements that use newly created Properties on themselves.

@Kirilloparma We have created and merged a patch that will hopefully fix the issue. It is due for deployment on Wednesday. Please do leave a comment here if it is solved or not, once a new Item type Property is created.

The problem seems to occur specifically, when a newly created Property is used in a stamement on itself, as is usually the case when creating "Wikidata property example" (P1855) statements. The reason for this is probably a loop that was introduced with “data type aware” value deserialization (T359421), which requires a data type lookup for deserializing values.

I believe this must have been an infrastructure issue which hasn't occured any more in the last three months.

Moving this back to "To Do" with a WIP patch for someone else to pick up or until I come back next week

How core is doing it

• Core's REST API search endpoint allows a single limit request parameter with a default value of 50 and an allowed maximum of 100
• No jumping to pages of the result
• See docs: https://www.mediawiki.org/wiki/API:REST_API/Reference#Parameters

One comment for product verification, @Ifrahkhanyaree_WMDE: when an Item is found by one of its aliases and has no label in the search language (or any of the fallback languages), then the label field in the search result will currently be null and the matching alias text will be shown in the match field. Let's discuss if we really want a label field in the search result and not something that can contain either a label or an alias, instead. Conceptually, this would be the "title" or "name" or "headline" of the search result, rather than an Item label.

Thank you for the investigation - sounds good and doable