Page MenuHomePhabricator

VisualEditor can't save edits (HTTP 404 error) when it was open for more than 24 hours while editing an old revision or after switching from wikitext
Open, Needs TriagePublic


VisualEditor can't save edits (HTTP 404 error) when it was open for more than 24 hours while editing an old revision or after switching from wikitext.

Similar error also occurs in this scenario when trying to review your changes, or when trying to switch to wikitext mode.

This was originally discussed here: T233127#5573527 but I'm making a new task because that one got huge.

If you can't save your edit because of this bug, try the following workaround:

  1. View the same page in a new browser tab
  2. Open the editor in this tab (make sure it does not restore your auto-saved edit – if it does, close the editor, discard your changes, and open it again)
  3. Copy-paste the entire page contents from the editor in the the old tab to the new tab
  4. Save in the new tab

Note that:

  • This workaround will overwrite any other edits on the page that happened in the meantime (without showing an edit conflict). Review the changes before saving to ensure you're not accidentally undoing others' edits.
  • This workaround may cause dirty diffs throughout the page. If you remember which parts you edited, copy-paste only those parts to minimize this.

Event Timeline

Relevant discussion from T233127:

I looked at the VE error logs [for HTTP 404 errors] after 10 October (assuming that's after the bug you found was fixed):


[There is a pattern of] etags like W/"<revid>/<uuid>[/stash]", except that the time in the UUID is older than 24 hours (compared to the time of the failing request). The oldest one was 99 days old, but there are also several 1-2 days old. This would indicate that the user kept the editor open for this long (plausible for 1-2 days, not really for 99…), or that it was cached somewhere for longer than it should be.


What should VE do when it turns out we're editing a render older than 24 hours (so it is no longer available in RESTBase, as you wrote earlier), so that we can avoid the second kind of failures? Is there a way for VE to send the original render back to RESTBase?

It is surprising to me that users are even able to send the data for transformation in these cases. AFAIK, a session lasts up to 9h after which it is scraped, so how does VE even obtain the metadata about the user/edit to be able to send the request to RESTBase? Isn't that info stored in the session? To more concretely answer your question, I am not sure there is something we can actually do, apart from (somehow) advertising to users that their edit is valid for only 24h (which, if you ask me, should be turned down to 9h to match the length of a session).

(…) I'll keep a VE open for 24 hours to see what actually happens with it. ;)

I tested this and got the expected results, namely:

  • When editing the latest revision of the page, if I never switched from wikitext, and if no one else saves an edit in the meantime, I could keep the editor open indefinitely and save my changes.
  • When editing an old revision, I couldn't save my changes, getting a HTTP 404 error.
  • When editing the latest revision of the page in wikitext, then switching to visual, I couldn't save my changes, getting a HTTP 404 error.


  • I did not actually save the changes, only opened the save dialog, which causes a paction=serializeforcache API query to be sent.
  • The edit token apparently expired (I guess this is the 9 hour session expiration that you mentioned), causing the first request to fail with 'badtoken' error, but VE just fetched a new one and retried, and the second request succeeded (or failed with HTTP 404).
    • In the old wikitext editor, I think in this scenario you'd get the 'session_fail_preview' error ("Sorry! We could not process your edit due to a loss of session data. …"), and you'd need to click "Publish" again, but saving the edit would be possible.

It looks like there is nothing further for the Editing team to do on this so we are tagging the Parsing team, Restbase is already tagged.

All the data needed for the edit is stashed on the backend with 24h TTL with an assumption that nobody would need more than 24h to complete an edit. We can increase this number if needed, but I think the cost in excess storage would far outweigh the benefits

(Documented a workaround in the description, based on the merged task)