Page MenuHomePhabricator

[zhwiki] Many info-level notices from ApiMobileView: mismatching number of sections from parser and split on page
Closed, ResolvedPublic

Description

There are many info-level notices from ApiMobileView reported in Logstash Kibana:

MobileFrontend\Api\ApiMobileView::parseSectionsData(): mismatching number of sections from parser and split on page Page:This Is An Example Error, oldid=2062311
/w/api.php?format=json&prop=*&pageprops=wikibase_item&noheadings=true&page=Page:This_Is_An_Example Error&sections=all&action=mobileview&sectionprop=toclevel%7Cline%7Canchor%7Clevel%7Cnumber%7Cfromtitle%7Cindex&thumbwidth=640

This issue appears most prevalent on User pages on zhwiki. It's my recollection that the Android app was the only consumer of this endpoint and that it only used it for Chinese.

Possibly related to T125578.

Event Timeline

Restricted Application added subscribers: Stang, Aklapper. · View Herald Transcript
Dbrant subscribed.

The mobileview API is still used by the mobile-html REST endpoint (in the zhwiki case), which is then consumed by Android and iOS.

I haven't looked at the code yet, but just a couple of observations from looking at Kibana: it looks like (1) this has been going on for at least the entire 90 days for which we have data in Logstash, and (2) it affects mostly if not exclusively non-mainspace pages.

https://logstash.wikimedia.org/goto/3b37707bb874f9fe5dd9607f9b1572fd

Edit: And it appears on a handful of other wikis, but the vast majority of occurrences are on zhwiki.

The skew toward zhwiki is probably because almost all of the traffic hitting ApiMobileView is coming specifically to zhwiki by way of either the Page Content Service or the Android app directly.

This section of code relies on an assumption that a split on /<h(?=[1-6]\b)/i yields the same number of sections as the parser thinks there are. On pages that break that assumption, this message is logged, the ApiMobileView sectionizer bails out, and the page HTML is returned in its entirety as a single section.

https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/5418d764cbca590a35831d177ffc799eaa21c65c/includes/Api/ApiMobileView.php#L563-L570

This seems mostly to occur on oddly formatted user pages.

In short, IMO this is just logspam. Would anyone object to just removing the wfDebugLog call?

Change 620132 had a related patch set uploaded (by Mholloway; owner: Michael Holloway):
[mediawiki/extensions/MobileFrontend@master] ApiMobileView: Remove debug logging from parseSectionsData

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

Change 620132 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] ApiMobileView: Remove debug logging from parseSectionsData

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

Jdlrobson claimed this task.