Indeed, and I have a note written down regarding production deployment to write a phabricator ticket for that soon.
We also have a call / more emails with WMF around the topci scheduled for next week.

Could you elaborate on this? If it is decided to not deploy that new suggester backend somewhere and talk to it, then I'm not sure what value these patches add and what they are needed for.
Or is this intended to be also used in other Wikibase installations?

So, we no longer support the wikibase-docker repository

In T284820#7160678, @Lucas_Werkmeister_WMDE wrote:

I’ve started looking at the patches, but I know almost nothing about the EventLogging parts.

TLDR this ticket is about code review of these things, not about deploying this thing to production right now.

Cross linking with T285064: Wikidata Bridge badtoken error which is similar but with a different stack

Cross linking with T285066: Wikidata Bridge error which is similar but with a different stack

Blocked on T285045 and might be declined if we just remove IE support from wikit

current docker file (wikibase 1.35)

Looks like this could be done now then.
Also removing @ItamarWMDE as he is no longer on camp!

In T204031#7124569, @Ladsgroup wrote:

Should we wait until T176312: Don’t check format constraint via SPARQL (safely evaluating user-provided regular expressions) is done and then move forward with it. It looks sensible to do it this way.

It is after the 10th June, so moving back to TODO
Removing @ItamarWMDE as he is no longer on camp

I think this is ready for another look now the db looking ticket is done.
Removed @ItamarWMDE as he is no longer on the camp

This part of this task looks good to me

They look enabled and green

Lowest as this hasn't come up in quite some time, and blocked on being able to do this "properly".

@Lucas_Werkmeister_WMDE you (and anyone else in the wmde devs npm team) should now have access to this package.

9:27 AM <marostegui> addshore: Maybe the issue is the schema change isn't being done o nthe same transaction, so while we drop the index and the queries arrive, there's no index until the new one is created
9:27 AM <marostegui> I can definitely change that for the next iterations

The query seems to come from https://gerrit.wikimedia.org/g/mediawiki/core/+/873118723cbe3c78e631bea44a66fb3659b9beab/includes/MediaWiki.php#1018
This code path is triggered as the health checks use http
Switching to https would avoid this code path and query for the health checks.
Though I guess we also want to look at why the query tries to scan the whole table?

Based on https://fa.wikipedia.org/wiki/%D9%85%D8%AF%DB%8C%D8%A7%D9%88%DB%8C%DA%A9%DB%8C:Common.js#L-449 and https://en.wikipedia.org/wiki/MediaWiki_talk:Common.js#Export_to_Wikimedia_Commons_button simply skipping the button when a page is in a category might be the only needed change.
This can easily be done in the existing code by checking getCategories on the page in question.

Sounds like a pretty good usecase

I can get behind that.
So the situation will get better once T272356 is done