Page MenuHomePhabricator

A page required a "dummy" edit to trigger a preview for it!
Closed, ResolvedPublic

Description

This was a weird behaviour I observed which I thought would be nice to bring to your notice. Here's what happened. Recently I saw that a link to a redirect page (Core memory) in an article (Random-access memory) didn't show a preview but showed the Looks like there isn't a preview for this page message in the popup. That surprised me and I started a thread noting this weird behaviour in this project's talk page in mediawiki.org.

The outcome of the thread was what surprised me! Another user tried to see if this issue got fixed in various ways such as,

  • Purging the redirect page
  • Purging the page pointing to the redirect
  • Null-editing the redirect page
  • Null-editing the page pointing to the redirect

none of which worked. Surprisingly a dummy edit to the redirect page did fix the issue! That was surprising as we couldn't find what a dummy edit did to the page that purging / null-editing didn't. So I thought I could bring this weird behaviour to the notice of the developers (of course, not limited to them :-) ) and see if we could find something about this.

Event Timeline

Surprisingly, I recently witnessed a possibly related issue this time with a direct link to the page. There's a link to the Natural language processing article in this Signpost article. When I hovered over it I got the Looks like there isn't a preview for this page message. This time purging the page resulted in the preview being shown.

I suspect something spooky is going on as I seem to be encountering the Looks like there isn't a preview for this page messages more often now for completely unknown reasons i.e., I see the message being triggered falsely which didn't seem to happen some time ago.

Jdlrobson subscribed.

The summary comes from RESTBase.
RESTBase caching works differently from MediaWiki and is not impacted by ?action=purge or null edits if I understand correctly, but services may be able to provide more guidance.

As far as I'm concerned there is an expected trade off that comes with the caching necessary for such a high usage endpoint and there isn't a bug here.

RESTBase caching works differently from MediaWiki and is not impacted by ?action=purge or null edits if I understand correctly, but services may be able to provide more guidance.

Actually it does, however it only purges Parsoid HTML because an optimization we have to not issue a purge request for summary/mobile content if HTML wasn't changed. Under normal circumstances this optimization is harmless, cause if HTML wasn't change summary can't possibly change either. But while migrating the storage we might've created some broken summaries. So I think action=purge and null edit should bypass the optimization and purge summary and MCS content directly.

I will have a look into the database on what exactly happened to these particular pages to confirm my idea, and if that's the case the fix is trivial.

Change 399692 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[mediawiki/services/change-propagation/deploy@master] [Config] Rerender mobile-sectionss and summary on MW purge and null edit.

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

Change 399692 merged by Ppchelko:
[mediawiki/services/change-propagation/deploy@master] [Config] Rerender mobile-sectionss and summary on MW purge and null edit.

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

Pchelolo claimed this task.

The fix has been deployed. Resolving.