Not very often. Actually, it seems to have completely disappeared about a week ago.

That's the others section in the paste above; the names are identical.

@kchapman yes. After the search team makes the jobs ready to be partitioned.

LGTM. We will also need statements for creating tables in beta.

This is the faulty request: https://de.wikipedia.org/w/api.php?action=query&titles=File:Tessie_Reynolds_02.tif&prop=imageinfo&iiurlwidth=320

@herron I believe this is the documentation for it https://wikitech.wikimedia.org/wiki/Event_Platform/EventGate/Administration#eventgate_chart_change

I was able to reproduce the problem in mediawiki-vagrant.

It doesn't seem to hav anything to do with the clinic duty. Untagging.

The endpoint was deployed https://en.wikipedia.org/api/rest_v1/#/Transforms/transformWikitextToMobileHtml

I don't want to expose externally what exactly our internal uris looks like, so the preq fix should be enough to achieev the goal of this.

PR: https://github.com/wikimedia/restbase/pull/1177

This seems older then wmf.17, I can find same-ish logs as early as wmf.13 which lines up from a fix for T180050 from @MaxSem, so CCing him.

Fixed and deployed. Resolving.

PR: https://github.com/wikimedia/change-propagation/pull/327

PR: https://github.com/wikimedia/change-propagation/pull/326

Untagging core platform team inbox since the ticket is already categorized.

To completely roll out any frontend caching, I've repeated the experiment from inside the production cluster with curl, same result - first request - reproducible, second request - not reproducible. However, I could only reproduce on wmdebug hosts. Trying to randomly query production hosts doesn't reproduce.

@Krinkle checkd again. I can both reproduce and not reproduce with a 200.

@Krinkle hm, ok, now I can reproduce, but it's interesting.

In T229379#5398334, @Shizhao wrote:

在T229379#5398056中，@Viztor写道：

In T229379#5398021, @Pchelolo wrote:

Hm. Trying to open https://zh.wikipedia.org/wiki/首页 both logged in, logged out and bypassing Varnishes gives me a normal page now while opening https://zh.wikipedia.org/wiki/Wikipedia:首页 gives the main page. Verified that served by HHVM. Is this still reproducible for others?

Appear to be correct after several tests here as well.

I am still able to reproduce this problem

Hm. Trying to open https://zh.wikipedia.org/wiki/首页 both logged in, logged out and bypassing Varnishes gives me a normal page now while opening https://zh.wikipedia.org/wiki/Wikipedia:首页 gives the main page. Verified that served by HHVM. Is this still reproducible for others?

Step 1: https://github.com/wikimedia/preq/pull/46

Checked again, now it works as expected. Resolving.

Checked the logs. The error indeed has disappeared.

Could we instead get rid of the EventBus::TYPE_* stuff altogether, and just use per-stream config? I'm not sure I fully understand the reasoning behind the different TYPEs.

Ye, we first need to deploy https://gerrit.wikimedia.org/r/c/mediawiki/services/restbase/deploy/+/521572

As I understand, MCS implementation for this is completed and we now need to add it to RESTBase.

Given that we're quite confident in eventgate now as we've transitioned all the kafka-main mediawiki events to it with no issues, and a fairly limited difference between eventbus and eventgate, I propose to do a fairly quick transition. 3 steps should be enough.

Clearly I need to figure out a single Kibana query that shows all mobileapps errors.

We have not observed this problem in production.

I don't think we will do it since there was no activity in 5 years after filing this task.