Last modified: 2014-03-13 16:54:27 UTC
Trying to "Edit" on http://en.wikipedia.org/wiki/List_of_Advanced_Dungeons_%26_Dragons_2nd_edition_monsters after a minute or so results in a popup "Error loading data from server: error. Would you like to retry?". Trying again, repeats the issue
I think this is probably related - editing on large pages such as California is considerably slower when using VE than it is using the old editor. A contributor complained of slowness with this edit (http://en.wikipedia.org/w/index.php?title=California&diff=562339624&oldid=562339237) and I found the same issue with mine (http://en.wikipedia.org/w/index.php?title=California&diff=562390635&oldid=562351322)
Re: timeouts, need to be either handled more gracefully or we'll need to VE-blacklist articles where it occurs for now.
Looks like the timeout here is on the Varnish/Parsoid side (API request on edit fails with error 504 after 60 secs).
Possibily we could, instead of giving the user the error code, we could have a pop-up saying "It looks like editor is currently unavailable; would you like to edit in source mode instead?" with an OK that takes you to action=edit and a cancel that returns you to action=view? Maybe for error-tracking purposes we could add <small>Parsoid returned 504</small> or <small>Parsoid not available</small> after the general call-to-action?
After upping the Varnish backend timeout to 5 minutes http://en.wikipedia.org/wiki/List_of_Advanced_Dungeons_%26_Dragons_2nd_edition_monsters?veaction=edit works now despite timing out in VE once. Hitting 'retry' re-joins the ongoing render, and returns the page pretty quickly. Previewing that page also works in about 30 seconds. You might want to tweak your timeouts / UI to reflect this change. As long as there is no timout from Varnish the render is still ongoing. More testing is needed with even larger pages. Bug 51053 will be closed when that is done.
(In reply to comment #5) > Previewing that page also works in about 30 seconds. Actually closer to 70 on re-test.
VE currently sets a 100s timeout, but in practice we often don't get there because the nginx proxies that terminate HTTPS and IPv6 traffic have a 60s timeout.
I'm pulling this from being a blocker to bug 50848, given the reduced impact now that it works on the second try.
(resetting assignee - I had issues trying to properly reproduce Parsoid timeouts like this on my machine)
We'll help. :-)
(In reply to James Forrester from comment #4) > Possibily we could, instead of giving the user the error code, we could have > a pop-up saying "It looks like editor is currently unavailable; would you > like to edit in source mode instead?" with an OK that takes you to > action=edit and a cancel that returns you to action=view? Maybe for > error-tracking purposes we could add <small>Parsoid returned 504</small> or > <small>Parsoid not available</small> after the general call-to-action? Basically done this after checking with Roan about how to reproduce this error, without the small text underneath. Confirm dialogs don't allow you to use HTML markup.
Change 118398 had a related patch set uploaded by Alex Monk: More gracefully handle situations where Parsoid returns a timeout failure code (HTTP 504) https://gerrit.wikimedia.org/r/118398
Change 118398 merged by jenkins-bot: More gracefully handle situations where Parsoid returns a timeout failure code (HTTP 504) https://gerrit.wikimedia.org/r/118398
