User Details
- User Since
- Jun 7 2021, 8:12 AM (206 w, 5 d)
- Availability
- Available
- LDAP User
- Isabelle Hurbain-Palatin
- MediaWiki User
- IHurbainPalatin (WMF) [ Global Accounts ]
Thu, May 22
Found during personal editing session: enwiki:Remineralisation_of_teeth (https://en.wikipedia.org/wiki/Remineralisation_of_teeth?useparsoid=0) OOMs on Parsoid.
Mon, May 19
Thu, May 15
This is the desired behaviour.
The fact that it's not consistent with common normalization practices is unfortunate but not an issue in practice either.
In the affected cases the solution is to either drop some modes from the parserTests or, if all modes are necessary, to consider splitting the parserTest in two for different modes.
The reason for this issue if that, if a data-parsoid is provided, then it's not created, and it's not considered a new node for serialization (which has an impact on spaces between bullet and text on lists, for instance), because it doesn't have the matching temp flag.
If it's NOT provided (... as it can happen if the only data-parsoid was dsr and it got normalized away, as we do), then we create a data-parsoid when checking if the node is new, and that data-parsoid has a "this is a new node" flag (and so it creates a space between the bullet and the content).
Tue, May 13
This is probably what was reported in https://phabricator.wikimedia.org/T200517#10785684, correct?
Mon, May 12
Throwing this in @cscott's direction's instead - I thought it might have been a side effect of my pipeline work, but it seems it predates it (comes from Ica09a4284c00d7917f8b6249e946232b2fb38011, as far as I can tell).
I don't have enough visibility on that part of the code to make the correct decisions (but I'm not convinced we'd *want* a pipeline there?)
Sat, May 3
Apr 17 2025
Apr 14 2025
I'm *reasonably sure* this is the same issue as T383004, closing as duplicate (and marking that one with the same tags)
Apr 11 2025
Putting this on the current backlog because I'd like to understand what's the status of it from our point of view.
https://logstash.wikimedia.org/goto/92bdfde8121cc98a9b7cee445b010666 seems to show still ~1500 of these a day coming from Wikidata - I think it's worth re-opening this one, if only because James' "stack trace" patch is attached to it. (Feel free to re-close and if I'm wrong in my assessment, obviously.)
I'm going to close this one as Resolved, because as far as I can see, this is not triggered via VE anymore. That error message is still present, but I think it is more related to T387453.
Adding to current board to consider handling the "temporary" fix sooner than later.
Apr 10 2025
I can't find instances of this issues anymore in Logstash. Please reopen if my logstash skills failed me.
Apr 8 2025
Removing Content-Transform-Team-WIP to avoid other folks looking into this during EssentialWeek; to be discussed in tech forum for exact triage.