Relevant discussion from T233127:

In T233127#5573527, @matmarex wrote:

I looked at the VE error logs [for HTTP 404 errors] after 10 October (assuming that's after the bug you found was fixed): https://logstash.wikimedia.org/goto/e6af566ed10567b8e30c7861e066ab96.

(…)

[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?

In T233127#5574016, @mobrovac wrote:

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).

In T233127#5582410, @matmarex wrote:

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

In T233127#5585805, @matmarex wrote:

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.

Notes:

• 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)

This is still an issue, recently reported by a user on pl.wp: https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#c-DaLoetz-2022-04-02T18:14:00.000Z-niemożność_zapisania_zmian

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: https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#c-DaLoetz-20230811114300-nie_moż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.

In T235822#9175588, @RoySmith wrote:

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.

I've given this a subtask T366721 for just improving the error message, since that seems uncontroversial. Ideally we can find a way to reapply the user's changes on a freshly stashed copy of the article, but there's obviously some conflict-resolution UX to work out there before we could have a general fix...