@RoySmith: Please add projects tags where you can when creating new tasks. Thanks!

Looks similar to T246143

In T250620#6069598, @Aklapper wrote:

Looks similar to T246143

Except that in my case, my changes always get saved. Well, maybe not on the "Error contacting the Parsoid/RESTBase server" example, but on all the others it was successfully saved.

@Joe might this be in any way related to the envoy changes?

In T250620#6069715, @ssastry wrote:

@Joe might this be in any way related to the envoy changes?

Probably not. https://logstash.wikimedia.org/goto/c9913945a883dafe1617ac23c65cd9a6 shows errors at least as far back as Jan 20 (3 months back and probably logstash doesn't have data before that), but, I see a spike starting April 3. Not sure what happened there.

@Pchelolo do you have any insight here?

Looks like HTTP 409s before April 3 changed to HTTP 404s. See https://logstash.wikimedia.org/goto/be58e75fdd5fbc6f33bc8644530b228a for HTTP 409 graph.
But, overall error rates itself didn't change ( https://logstash.wikimedia.org/goto/39c21af1e325e470b33d30c7d425a644 is the error rate across all non-200 status codes ).

The HTTP 409 comes from Parsoid ( https://github.com/wikimedia/parsoid/commit/9cb12e3ee84671ea3a23be79b41777afe3713154 ) as a fix for T238934: Call to a member function getContent() on null. However, I doubt this code was triggering before April 3 at this rate and now swtiched to 404 now.

So, looking at RESTBase, it also has code for HTTP 409 ( https://github.com/wikimedia/restbase/blob/master/sys/action.js#L18 ) -- https://github.com/wikimedia/restbase/blob/master/sys/action.js#L99-L103. So, my hunch is something changed in how RESTBase handles this scenario? For example, editconflicts would trigger 409.

Anyway, at this time, I will let @Pchelolo or VE folks poke around.

I can reproduce @RoySmith's error with this edit. The edit itself saved but the VE dialog stuck around.

So, @RoySmith, did you encounter the http 404 when you hit "Publish Changes" again? If so, that might explain the 409 / 404 (without looking into the code itself). And, in that the case, the real error would be the lingering VE dialog that wouldn't dismiss after save.

To be honest, I don't remember the details around the 404. I only got it that one time, and haven't seen it since. If it happens again, I'll try to grab more data.

Note: in my original report, I wrote "4040"; that's obviously a typo. Should be "404".

@matmarex will investigate

I see this behavior almost exclusively at the English Wikivoyage, and typically when I've been editing for a while. My changes have *always* been published. Once it starts, it pretty much keeps going until I quit editing for the day.

I see this in Firefox (all the versions for the last ~two years) on macOS.

Another user is apparently experiencing the same thing (and managed to capture a video of it happening). See Village Pump thread here.

I see this error in the console when trying to save the changes on that page, it seems to be coming from Kartographer code:

jQuery.Deferred exception: map.remove is not a function TypeError: map.remove is not a function
    at https://en.wikipedia.org/w/load.php?lang=en&modules=ext.kartographer.linkbox%2Cstaticframe%7Cjquery%7Cmediawiki.router%7Cwikibase.client.linkitem.init&skin=vector&version=1s91l:3:879
    at fire (https://en.wikipedia.org/w/load.php?lang=en&modules=ext.kartographer.linkbox%2Cstaticframe%7Cjquery%7Cmediawiki.router%7Cwikibase.client.linkitem.init&skin=vector&version=1s91l:50:209)
    at Object.fireWith (https://en.wikipedia.org/w/load.php?lang=en&modules=ext.kartographer.linkbox%2Cstaticframe%7Cjquery%7Cmediawiki.router%7Cwikibase.client.linkitem.init&skin=vector&version=1s91l:51:402)
    at Object.fire (<anonymous>:405:482)
    at VeInitMwDesktopArticleTarget.ve.init.mw.DesktopArticleTarget.replacePageContent (<anonymous>:26:680)
    at VeInitMwDesktopArticleTarget.ve.init.mw.DesktopArticleTarget.saveComplete (<anonymous>:18:854)
    at fire (https://en.wikipedia.org/w/load.php?lang=en&modules=ext.kartographer.linkbox%2Cstaticframe%7Cjquery%7Cmediawiki.router%7Cwikibase.client.linkitem.init&skin=vector&version=1s91l:50:209)
    at fireWith (https://en.wikipedia.org/w/load.php?lang=en&modules=ext.kartographer.linkbox%2Cstaticframe%7Cjquery%7Cmediawiki.router%7Cwikibase.client.linkitem.init&skin=vector&version=1s91l:51:402)
    at mightThrow (https://en.wikipedia.org/w/load.php?lang=en&modules=ext.kartographer.linkbox%2Cstaticframe%7Cjquery%7Cmediawiki.router%7Cwikibase.client.linkitem.init&skin=vector&version=1s91l:53:751)
    at process (https://en.wikipedia.org/w/load.php?lang=en&modules=ext.kartographer.linkbox%2Cstaticframe%7Cjquery%7Cmediawiki.router%7Cwikibase.client.linkitem.init&skin=vector&version=1s91l:53:808)

The HTTP 404 error is probably unrelated, and it seems that we have a separate task about that: T246143: RESTBase HTTP errors preventing VisualEditor from saving. I'll restore the original task title here, the current one is confusing.

So this seems to be caused by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Kartographer/+/588121, but I'm not sure what is the proper way to fix it. CC @TheDJ in case you know an obvious solution. I'll keep digging later otherwise.

I remember a similar issue reported on Persian Wikipedia around August 2019 (many users experienced it, only when using Visual Editor). At the time, it was limited to Persian Wikipedia, but I think no one never reported it here. Maybe it's been caused by something deeper?

Change 592262 had a related patch set uploaded (by TheDJ; owner: TheDJ):
[mediawiki/extensions/Kartographer@master] Do not use remove() on maplinks

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

This issue really only surfaced in VE+static img maps. On livepreview, we always use dynamic maps and then the wikipage.content loop of staticframe usually only triggers once. Except when using VE.

Change 592262 merged by jenkins-bot:
[mediawiki/extensions/Kartographer@master] Do not use remove() on maplinks

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

Change 592718 had a related patch set uploaded (by Bartosz Dziewoński; owner: TheDJ):
[mediawiki/extensions/Kartographer@wmf/1.35.0-wmf.28] Do not use remove() on maplinks

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

Change 592718 merged by jenkins-bot:
[mediawiki/extensions/Kartographer@wmf/1.35.0-wmf.28] Do not use remove() on maplinks

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

Mentioned in SAL (#wikimedia-operations) [2020-04-27T18:21:44Z] <urbanecm@deploy1001> Synchronized php-1.35.0-wmf.28/extensions/Kartographer/modules/: SWAT: 6cd2847: Do not use remove() on maplinks (T250620; T251053) (duration: 00m 58s)

The fix should now be deployed on all Wikimedia wikis.

On cs.wiki it works now, so should be OK.