Needs to verify if this happens within the EventBus extension

Assigning to @ArthurTaylor as he pushed the change. Thank you for fixing it!

Looks like it is no longer pending. Someone had to trigger the job, I didn't find any entries in SAL to find out who did it.

The plan for AttributionAPI is to be fast; our target is to provide a response within 200-300ms, and a 500ms a hard no-go zone. That's why we have some restrictions and we made some decisions to make sure we can provide valuable responses.
At this moment non-flagged wikis - as @Tsevener says - we use parsoid cache ( which has 80~90% hit ratio ). In our scenario, the hit ratio for Attribution endpoit is 97% in last two weeks. Currently. the API responds within 60ms, but it's worth mentioning that the majority of requests come for File attribution ( Authors & License ). With regard to flagged_revs wikis - this is something we initially skipped as a better solution ( signal from Analytics ) was planned. The current references_count is more an interim solution than a final solution.

This is caused by current limitations of the AttributionAPI - fetching references is handled by retrieving the page HTML and performing simple id="cite-note-... search on the output.

I'm going to decline this ticket in favour of T434930: Create MobileAppRedirect special page to redirect users to the correct app store to download the Wikipedia App and T437087: AttributionAPI: Use Special:MobileAppRedirect for the app download CTA, Wikipedias only.

Sorry for confusiuon, yesterday I learned about MobileApp Extension and it feels like a much better place to put the SpecialPage. @MGoncalves-WMF can you move the code you made to MobileApp extension? Sorry for catching this so late.

Also to follow-up - is it only English Wikipedia? My initial assumption was "All wikipedias", without narrowing it down just to English. This is not a deal breaker, but would be good to know whether we want to serve different CTAs to different wikis - as this would impact the solution a bit.

In T437273#12299486, @SomeRandomDeveloper wrote:

In T437273#12299470, @pmiazga wrote:

In T437273#12298280, @Urbanecm wrote:

In T437273#12297954, @pmiazga wrote:

That's a really good point, but looks like it doesn't work. If I set the readonly in MWDebug the Special:Version still works. The logging-in doesn't work.

I'm not sure I follow. Are you saying that it is not possible to log in (authenticate) with the read only mode enabled? Or are you talking about something different?

What I was saying - that if I set the read-only mode with WikimediaDebug toolbar I could see the site goes into read-only mode - ( as for example, logging-in is not available ), but this issue was still existing. In other words, setting the WikimediaDebug readonly didn't trigger this behaviour.

The patch was deployed to prod around 12 PM, so if you tried after that time, then presumably the behaviour didn't occur because the patch fixed it, and not because readonly doesn't work. The code to enable read-only at https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/4e730e2c03b19970aa3b34a498bb91abb93e7b48/wmf-config/CommonSettings.php#362 at least seems correct to me, and when enabling the option in the extension I can't edit or log in.

In T437273#12298280, @Urbanecm wrote:

In T437273#12297954, @pmiazga wrote:

That's a really good point, but looks like it doesn't work. If I set the readonly in MWDebug the Special:Version still works. The logging-in doesn't work.

I'm not sure I follow. Are you saying that it is not possible to log in (authenticate) with the read only mode enabled? Or are you talking about something different?

just renamed the ticket, just to pinpoint that the issue is specific to CentralAuth extension, not MW Core.

You cannot set individual wikis to read_only,

If we want to test it - we can always set testwiki to read_only mode to test this change.

@MGoncalves-WMF can we rename the Special page to be MobileAppRedirect ? In case a different project gets an app, we don't want to create a new page, instead. I think that using MobileAppRedirect should be sufficient.

Is this ticket still resolved? I can see a PR got restored and I wonder if this is something we want to implement anyway?. The gerrit change looks good, but I have no clarity if this is something we want to merge.

This sounds good, only a minor nitpick - lets keep it as a map ( PHP Assoc array, just use array_flip() in the mediawiki job ) - in case when array can have up to 7k elements - it's gonna be much faster to do isset($map[$pageId]) instead of full lookup in_array($pageId, $array).

Moving to in-progress to reflect the state. @Ladsgroup are you going to work on deprecation too or do you want us to pick it up?

Moving to waiting on our board to reflect the state, as the issue is fixed.

Moving back to in-progress, looks like this is live and no longer blocked. @Krinkle does it need more work or can we close this?

Im going to resolve this ticket - in the other thread I'll try to find out why this didn't break on prod.

Assigning MediaPlatform team as this may be their territory now. @JTweed-WMF feel to unassign if othewise.

Looks like this is still happening. Logstash shows 9 errors in last 24hours, 10 errors in last 30 days.

Looks like we came up to the same conclusion. I was going to remove exact same lines. The only thing that confuses me here is why this didn't break on prod CI? As to me, those tests were failing locally both with Echo and Echo+Flow, and from what I see most likely it would break with any set of extensions.

In T427053#12265350, @Nardog wrote:

In T427053#12265040, @pmiazga wrote:

IMHO - the issue is on Firefox side and they should fix it

Can you elaborate? Why is it incumbent on a browser to behave a certain way when it encounters something the HTML specs prohibit?

The only thing that comes to my mind is this line https://gerrit.wikimedia.org/g/mediawiki/extensions/Flow/+/6314e20f9c3cfe2963e6a27a6ac73623dc6e11a1/includes/EchoHooks.php#25 - where Flow would stop the Echo event to happen, thus there would be just a single call from MediaWiki\RecentChanges\ChangeTrackingEventIngress::updateNewTalkAfterPageUpdated().

The test fails locally with Core+Echo, but it also fails with Core+Echo+Flow. I think maybe my flow is misconfigured, because my understanding is that probably it should be somehow set up to capture/modify Talk pages edits, which would mean one of the calls is not triggered. Let me check Flow configs.