Another more serious article:

https://en.wikipedia.org/api/rest_v1/page/html/P._V._Sindhu shows the warnings as well. However, when I parse this with Parsoid locally, it doesn't show up. So, something is causing preview mode warnings to be displayed. @GWicke, know more about this? I think there was some related bug that I remember seeing recently that @aaron was working on. I cannot find that bug handy, but flagging aaron in case he knows more.

Thanks @ssastry !

The current version of https://en.wikipedia.org/api/rest_v1/page/html/P._V._Sindhu does not show the warning any more. Perhaps the module was edited to no longer use this hack?

So wait this happens "incidentally" ? That sounds like the parser is not varied on preview mode (or revisionid) and then the results are being cached ?

https://en.wikipedia.org/api/rest_v1/page/html/Einstein_family/777055196

Hmm, right this is not incidental at all. Parsoid shells out to action=parse api for templates of course. And while you can pass title context to such an invocation, you cannot pass revisionid context (Because that's not a normal use case).

Template parsing with title context:
https://en.wikipedia.org/wiki/Special:ApiSandbox#action=parse&format=json&title=Einstein+family&text=%7B%7BInfobox+person%7Cethnicity%3Ddeveloper%7D%7D&contentmodel=wikitext

Since we are parsing unrevisioned "text" here, instead of a page, the RevisionID check used by the template fails.

Template parsing with attempt at revision context:
https://en.wikipedia.org/wiki/Special:ApiSandbox#action=parse&format=json&title=Einstein+family&text=%7B%7BInfobox+person%7Cethnicity%3Ddeveloper%7D%7D&oldid=777055196&contentmodel=wikitext

This could be 'fixed' by making oldid of action=parse work with the text parameter, as well as with the page parameter. Then for the relevant getParserOutput(), we can pass the revisionid explicitly to the parser.

I'm pretty sure there was a pretty significant discussion regarding why these show up in preview either on en.wp or elsewhere in Phabricator.

@Izno the reason why en.wp wants these errors to only show up in preview is because they are often rather technical. By having them in the content, it affects the readability for too many users. By having just a tracking category, there would be too little incentive for editors to update the content. It was figured out that in preview mode {{REVISIONID}} return '', and this is the hack to only show that content in a preview. Unfortunately, Parsoid since then is using a mode that will also cause {{REVISIONID}} to return empty when using this template, and thus the error is no longer preview specific.

And now you have a typical situation of: editors started using something for a different purpose than it was intended, and developers either need to keep supporting it, come up with an alternative, or piss off lots of people.

No real winners :)

In T141403#3209799, @TheDJ wrote:

@Izno the reason why en.wp wants these errors to only show up in preview is because they are often rather technical

Right, I understand the rationale. I was making the comment that I believe there's a technical discussion somewhere about a possible replacement. The location of that discussion after some looking around was at T137900: Deal with poor edit stash hit rate due to Lua modules using {{REVISIONID}}, which is actually linked in this task's parent task .