Page MenuHomePhabricator

[Regression pre-wmf.23] REST API on Beta cluster returns content of different pages than requested (breaks VE)
Closed, ResolvedPublic

Description

On Beta cluster I can't open mobile VE when I click on the Edit icon.
There is no error in the console, it's just not doing anything

Event Timeline

It's probably the map. It's always maps. :-(

Ryasmeen triaged this task as Unbreak Now! priority.Sep 25 2018, 11:39 PM

Okay I am gonna mark it as UBN, since it makes mobile VE totally unusable for certain pages.

Ryasmeen renamed this task from [Regression pre-wmf.23] Can't open mobile VE when I click on Edit icon on Beta cluster to [Regression pre-wmf.23] Can't open mobile VE when I click on Edit icon on Beta cluster for pages that includes maps.Sep 25 2018, 11:50 PM
Ryasmeen renamed this task from [Regression pre-wmf.23] Can't open mobile VE when I click on Edit icon on Beta cluster for pages that includes maps to [Regression pre-wmf.23] Can't open mobile VE when I click on Edit icon on Beta cluster for pages that include maps.

Actually, I don't think it's about maps, it's also not opening for this page which only has one line text: https://en.m.wikipedia.beta.wmflabs.org/wiki/Newpageload

Ryasmeen renamed this task from [Regression pre-wmf.23] Can't open mobile VE when I click on Edit icon on Beta cluster for pages that include maps to [Regression pre-wmf.23] Can't open mobile VE when I click on Edit icon on Beta cluster for some pages.Sep 25 2018, 11:57 PM

This might be unrelated, but when opening the mobile editor in wikitext mode for that page, it works for me. Switching to Visual mode instead, the thing crashes and goes back to read mode. No error is logged to the console, but I do see in the network panel that the request to Beta Cluster's Parsoid for https://en.m.wikipedia.beta.wmflabs.org/wiki/Newpageload is responding successfully... with the contents of an unrelated page, the wiki's Main Page:

https://en.m.wikipedia.beta.wmflabs.org/api/rest_v1/page/html/Newpageload/378098?redirect=false

Screen Shot 2018-09-26 at 02.24.46.png (424×1 px, 150 KB)

That might be part of the problem.

I tried to edit https://en.m.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_(WMF)?debug=1 and stepped through all the init code line by line to find out where it fails. And it fails here:

extensions/VisualEditor/modules/ve-mw/init/ve.init.mw.ArticleTarget.js
				this.loadFail(
					've-api',
					'Revision IDs (doc=' + docRevId + ',api=' + this.revid + ') ' +
						'returned by server do not match'
				);

When it fails, docRevId = 377057, this.revid = 384154. Revision 377057 actually is a revision of a different page: https://en.m.wikipedia.beta.wmflabs.org/?oldid=377057

In hindsight, I could have found it out more easily by editing on desktop, which actually shows the error message: https://en.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_(WMF)?veaction=edit

image.png (980×1 px, 142 KB)

Looks like the REST API is returning some bogus results. I don't think it's a VE bug.

matmarex renamed this task from [Regression pre-wmf.23] Can't open mobile VE when I click on Edit icon on Beta cluster for some pages to [Regression pre-wmf.23] REST API on Beta cluster returns content of different pages than requested (breaks VE).Sep 26 2018, 11:09 AM
matmarex edited projects, added RESTBase, VisualEditor (Current work); removed VisualEditor.

The REST API is returning the correct, latest revision, which is 384154. It seems to me that 377057 is somehow being set by VE, as asking the REST API for a revision of a title that doesn't match the title would result in a client error (which is not the case here).

But, weirdly, I cannot reproduce this problem. When I ve-edit the page, VE opens just fine for me (on desktop).

It seems to be working correctly now, but as evidenced by the screenshots, it was not working correctly this morning.

It is a bit upsetting if it magically broke and then fixed itself with no human intervention.

While this is a serious issue, I don't think it is a blocker for 1.32.0-wmf.23 deployment:

  • The bug seems like it is in RESTBase rather than MediaWiki, so deploying a new MW version shouldn't affect it
  • VE actually detects the erroneous results from the REST API and shows an error (if it didn't, user trying to save the changes could replace the page with unrelated content)
  • It's not happening right now and we don't know how to reproduce it…

Here's a guess.

377057 is the latest revision of the Main_Page.

VE is asking for 1.7 content from Parsoid,
https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/master/includes/ApiVisualEditor.php#L101

RESTBase is hitting https://github.com/wikimedia/restbase/pull/1069 since the stored version is 1.8 and asking for a downgraded version from Parsoid but not specifying a title or revid and something is going wrong there?

I've tried various things in RB but I simply can't get RB to respond with 377057.

curl 'localhost:7231/en.wikipedia.beta.wmflabs.org/v1/page/html/User:RYasmeen_(WMF)' -H'Accept: text/html; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/HTML/1.7.0"' results in a 200 that returns the rev 384154 with the content type text/html; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/HTML/1.8.0". Same for requesting localhost:7231/en.wikipedia.beta.wmflabs.org/v1/page/html/User:RYasmeen_(WMF)/384154.

Well, if I do,

arlolra@deployment-restbase01:~$ curl 'localhost:7231/en.wikipedia.beta.wmflabs.org/v1/page/html/Tony_Pittman' -H'Accept: text/html; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/HTML/1.7.0"'
<!DOCTYPE html>
<html prefix="dc: http://purl.org/dc/terms/ mw: http://mediawiki.org/rdf/" about="https://en.wikipedia.beta.wmflabs.org/wiki/Special:Redirect/revision/377057"><head prefix="mwr: https://en.wikipedia.beta.wmflabs.org/wiki/Special:Redirect/"><meta charset="utf-8"/><meta property="mw:pageNamespace" content="0"/><meta property="mw:pageId" content="1"/><link rel="dc:replaces" resource="mwr:revision/354925"/><meta property="dc:modified" content="2018-03-18T05:52:05.000Z"/><meta property="mw:revisionSHA1" content="bcc5ae94bcb801b45c98c7645e296be1eff60027"/><meta property="isMainPage" content="true"/><meta property="mw:html:version" content="1.8.0"/><link rel="dc:isVersionOf" href="https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page"/><title>Main Page</title> ...

vs

arlolra@deployment-restbase01:~$ curl 'localhost:7231/en.wikipedia.beta.wmflabs.org/v1/page/html/Tony_Pittman'
<!DOCTYPE html>
<html prefix="dc: http://purl.org/dc/terms/ mw: http://mediawiki.org/rdf/" about="https://en.wikipedia.beta.wmflabs.org/wiki/Special:Redirect/revision/52317"><head prefix="mwr: https://en.wikipedia.beta.wmflabs.org/wiki/Special:Redirect/"><meta property="mw:TimeUuid" content="6dba5705-abc7-11e8-abcc-98dcecb75195"/><meta charset="utf-8"/><meta property="mw:pageNamespace" content="0"/><meta property="mw:pageId" content="3504"/><link rel="dc:replaces" resource="mwr:revision/0"/><meta property="dc:modified" content="2011-09-27T05:32:19.000Z"/><meta property="mw:revisionSHA1" content="10b4ced549cacadc636c6f9d56e00f8932ed6408"/><meta property="mw:html:version" content="1.8.0"/><link rel="dc:isVersionOf" href="https://en.wikipedia.beta.wmflabs.org/wiki/Tony_Pittman"/><title>Tony Pittman</title> ...

Note that the original issue found, as well as VisualEditor's logic in general, always asks for ?redirect=false. Might be unrelated, but just noting it here.

The stored content for User:RYasmeen_(WMF)/384154 is now at 2.0.0, which downgrades just fine, since it's a major version downgrade, and is probably why you couldn't reproduce this. The bug is somewhere in that minor version downgrade path.

mobrovac claimed this task.
mobrovac edited projects, added Services (done); removed Services (attic).

You were right, @Arlolra . The problem was in downgrading the minor versions. I have deployed PR 1069 and now the correct content is returned. Resolving.

To elucidate why the Main_Page was showing up,

Other than the fix that was applied, is there anything required?

Hmm, I am still not being able to open those pages with mobile VE. Shouldn't the fix that was applied work by now?

@Ryasmeen can you list the titles you are trying now? I bet my right hand it's Varnish cached something wrong.

@Ryasmeen try now

The second page is loading now with VE, but the first page still doesn't for some reason.

@Ryasmeen try now

The second page is loading now with VE, but the first page still doesn't for some reason.

WFM. Mind trying again?