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, HighPublic


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. Open your sandbox in the visual editor in another browser tab
  2. Copy-paste the entire page contents from the editor in the article to your sandbox – you may save the changes in your sandbox at this point, although it's not necessary
  3. Go back to the article, close the visual editor (discarding your changes), then open the visual editor again (make sure it does not restore your auto-saved edit)
  4. Copy-paste back from your sandbox to the article, then save your changes

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)

After T320529 this has a better error message: "No stashed content found for XXX" but the bug still occurs.

There was another report at pl.wp:żna_zapisać_artykułu_w_brudnopisie

I've been hearing about this from several different users (student editors in Wiki Education programs) in the last week, including a report that it's happening repeatedly for the same user. The error screenshots I've been sent show the "No stashed content found" message.

Looking at the suggested workaround instructions:

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)

I'd be hesitant to suggest that because the "discard your changes" part appears to increase the probability that you will lose the only copy of your unsaved work. A better strategy would be to open the editor in an incognito window, or perhaps using another browser, so you get clean browser-side state. Then proceed as follows. When trying to recover from a possible loss-of-data situation, the last thing you want to do is intentionally discard data which has not yet been durably preserved.

I know this is an old ticket, but it still might make sense to update the proposed workaround to avoid leading people down a dangerous path.

A better strategy would be to open the editor in an incognito window, or perhaps using another browser, so you get clean browser-side state.

I wouldn't want to suggest that, since that way it's too easy to accidentally save your changes while logged out under your IP address. I'll edit the workaround to copy the changes to your sandbox instead first, which should also avoid losing your data. Feel free to edit it as well (just don't make it too long).

The sandbox idea works for me, thanks.

Wiki Education has been getting a lot of reports about this from student editors this term. (We've heard directly from students or instructors about 20 times, which is the tip of the iceberg because most people who hit this bug don't report it to us.)

If there's no prospect of fixing it any time soon, it should have a user-friendly error message. "No stashed content found" is cryptic and provides no hint about what actually went wrong from a user perspective, how to avoid it happening again, or how to work around it.