User Details
- User Since
- Oct 7 2014, 5:34 AM (493 w, 2 h)
- Availability
- Available
- IRC Nick
- subbu
- LDAP User
- Subramanya Sastry
- MediaWiki User
- SSastry (WMF) [ Global Accounts ]
Thu, Mar 14
This diff also showed up on enwikivoyage pages.
Indeed! The pages linked in the description look fixed now!
Wed, Mar 13
Tue, Mar 12
This seems to affect a lot of pages on enwikivoyage.
Mon, Mar 11
Fri, Mar 8
The plwiki URL is a template page and is a mess that Parsoid doesn't know how to render properly ... I consider that an edge case. The use of the template itself on article pages seems to render fine. So, for now, ignoring that page.
I don't see anything to be done here in parsoid, so adding the tracking tag instead.
Thu, Mar 7
We may not need to block on any of the tasks above actually. It is sufficient to simply check (while processing a heading) if it is nested inside an extension (which is a cheap and robust check and doesn't depends on having explicit nested boundaries).
Wed, Mar 6
We are starting to run up against this problem again in multiple instances while trying to tackle Parsoid read view compatibility bugs. So, it is time to pick this up and implement a reasonable b/c solution that only introduces a minor HTML spec version bump.
@ihurbain identified this as yet another instance of T214241: data-mw info is clobbered by template annotations
But, there are other ideas in T295171: Use data-mw.rangeId="t:...." instead of "about" for template ranges and T214241: data-mw info is clobbered by template annotations that we could explore.
This is actually a near-neighbor of T214241: data-mw info is clobbered by template annotations. The section-wrapping / TOC code isn't able to demarcate the boundary of an extension because the extension output happens to be the first element of a template and so the extension-content boundary is not demarcated. And, so the section wrapping code treats the entire template wrapped DOM forest to be extension content and suppresses headings from it (as required by T355092: Parsoid / legacy parser disagree whether to include extension content in TOC).
Given the six 9's reliability that Joe cited above ( T249745#958681 ) and Aaron's logstash dive over last 15 days and analysis ( T249745#9592919 ), it seems that we could probably close this task as not additionally actionable.
Given that Tim abandoned his attempt and given this is an edge case (see discussion on gerrit patch), I am inclined to decline this since we aren't going to go tweak this now -- we just need to make sure Parsoid's ids match the existing ids for b/c reasons.
Tue, Mar 5
Mon, Mar 4
Sun, Mar 3
There is also T310544: Ensure MobileFrontend works with Parsoid read views for discussion tools in case there is any work to be done that is specific to DiscussionTools beyond what is done in T269499.
Yes, this is all blocked on T269499: [Epic] Make MobileFrontend compatible with Parsoid HTML -- I think focus should be on that task and this should either be closed as dupes of those (or made subtasks of that). Something the Web Team can figure out based on their triaging.
This and all the other mobile web tasks filed by you and Jon are all blocked on T269499: [Epic] Make MobileFrontend compatible with Parsoid HTML.
Sat, Mar 2
URL triggering the "2 byte sequence" in the last 2 weeks:
- /w/rest.php/ks.wikipedia.org/v3/page/pagebundle/%D8%B1%D9%8F%DA%A9%D9%8F%D9%86%3A511KeV/85479
Couple urls triggering this in the last 2 weeks
- /w/rest.php/en.wikipedia.org/v3/page/pagebundle/Shringara-manjari-katha/1184261178
- /w/rest.php/en.wikipedia.org/v3/page/pagebundle/Ajayapala_(Chaulukya_dynasty)/1197445390
There are a number of requests where the request URL uses a revid zero:
- /w/rest.php/en.wikipedia.org/v3/page/pagebundle/Cyborgs_(film)/0
- /w/rest.php/en.wikipedia.org/v3/page/pagebundle/Monica_Bellucci/0
- /w/rest.php/en.wikipedia.org/v3/page/pagebundle/11/0
Similar to T351931, this may just be another case where Parsoid isn't adding these links to metadata?
The bulk of Parsoid library's testing isn't through the unit tests in tests/phpunit but through parser test runs in tests/parser/* .... if we can find a way to hook those test runs to the coverage tool, we might get better numbers. There is ongoing work to make parser test runs more phpunit friendly, so maybe that will do the trick? In Parsoid/JS land,
Fri, Mar 1
Thu, Feb 29
Tue, Feb 27
It doesn't show up in production because the logging level is set to warn or higher there. Separately, we should probably suppress non-actionable logspam like this (there are a few of those in Parsoid).
Sun, Feb 25
Yes, this is known. We cannot eliminate all of them -- since some of them are harmless / informational / false positives. We could maybe suppress them going forward. We'll chat about that.
Sat, Feb 24
Fri, Feb 23
Thu, Feb 22
Not to say there isn't anything to investigate here, but if I zoom out that logstash board to 1 month, the errors seem to be fluctuating up and down within that window. But yes within a smaller time window, you see more dramatic fluctuations.
Tue, Feb 20
Feb 16 2024
Feb 15 2024
The analysis in the description is not entirely right. Turns out that the handle empty elements pass was not setting mw-empty-elt class for template output wrappers!