Ghost: "Someone else is editing" errors when no-one else is editing

[kevinansfield]

Issue Summary

We've had a number of reports where "Saving failed! Someone else is editing this post." errors are shown when it's not possible that anyone else was editing the post.

So far we have no reliable reproduction case although it does appear to occur more frequently on remotely hosted instances than local development instances.

My best guess at how this could happen:

1. First save request is fired by the admin client and the server handling/response is delayed for some reason
2. A second save request is fired (this could be through Cmd-S, an autosave, or editing a PSM field)
3. Server handles/responds to the first request, updating the updated_at field
4. Server handles/responds to the second request which at this point has an old updated_at value triggering the collision warning

The above scenario is much more likely to happen on systems that have occasional slow responses.

Reproduction steps

I've been able to use these steps to reproduce locally after tracing a production error and examining the logs for collision errors:

1. Open a post in the editor
2. Switch to "Slow 3G" throttling in Web Inspector
3. Make a change to the post body
4. Fairly quickly open the PSM then check the "feature" or "page" checkboxes
5. 🤞 You'll get a collision error

This is happening because the save routines in the post settings menu bypass the sequential saves in the main editor controller and so are prone to triggering the "best guess" scenario mentioned above.

TODO

• [x] evaluate debug logs
• [x] define a new save task in the editor base controller mixin that is exposed to the PSM component and replace all instances where the PSM saves the post model directly with the save task (https://github.com/TryGhost/Ghost-Admin/pull/901)
  
  
  
  • the new save task will be in addition to the current save task because the current task has additional publishing workflow requirements that the PSM inputs skip
  
  
  • the new save task will be part of the saveTasks group so that all save requests are queued to prevent collision errors
  
  

[kevinansfield]

I can review the client code to make sure that all post save requests are queued properly so that we aren't submitting old updated_at values by making sure that the last request has finished and updated the client's data before the next request is started. This _should_ already be the case but there may be something that's been missed.

[dkbast]

Any progress on this? I usually have this happening when I have multiple editors open (but with different articles). The timing varies from almost immediately to after an hour of writing.

[kirrg001]

Any progress on this? I usually have this happening when I have multiple editors open (but with different articles). The timing varies from almost immediately to after an hour of writing.

Not yet, we were unable to reproduce, but thanks for the advice. We will look into this as soon as possible.

[kirrg001]

@dkbast I am unable to reproduce 😔

[stefanovazzocell]

I can report a similar case:
I was editing in Chrome and then I closed the browser (I thought autosave took care of the article). No warning from the page when I closed the browser.
I updated Windows and went back to my article and ... nothing was there. I start typing it again (after getting a bit upset) and the red banner appeared. "Saving failed! Someone else is editing this post.".

UPDATE: Can you post a way to disable the warning? I can't get on editing the article... Restarting the server/ Updating it/ Stopping and Starting it... nothing works

[kirrg001]

@stefanovazzocell Sorry to hear that and thanks for sharing. Are you on the latest Ghost version?

[stefanovazzocell]

I'm using the latest version (the problem started with 1.9.* and continued when I updated). It seems to be fixed now, but I cannot confirm until I post another entry...

[kirrg001]

Even with delayed server responses and multiple requests to update a post, i am not able to reproduce. The server + client can handle such edge cases. I am not sure what else to test here. If any of you can provide steps to reproduce, that would be very helpful! Thanks 👍

[kirrg001]

I've added a subtask on top.

[ ] evaluate debug logs

[kevinansfield]

Added verified reproduction steps for local testing to the original issue.

I've spent too long today trying to get an automated test for this but I keep running into issues with the runloop and our API mock service not running concurrent saves so I'll just PR the necessary fixes.

[kevinansfield]

🤞 the false positive collision detections are all resolved with https://github.com/TryGhost/Ghost-Admin/pull/901 (released with Ghost 1.16.2) - if we still see issues on Ghost(pro) or others are still experiencing it we can re-open

[chrissainty]

Hi,

I'm currently using Ghost 1.19.0 and have just started being plagued by this warning. I've not seen it before, I have been using Ghost for about 7 months now. But in the last week or so I'm now getting it whenever I am writing. The only way I can cure it is to restart the browser. There doesn't seem to be any rhyme or reason to it that I can tell. Which I know is not a lot of use in terms of diagnosis. I will continue trying to find some common step for reproduction and if I do I will post them here.

[kirrg001]

@chrissainty Thanks, that would be super helpful!

The only way I can cure it is to restart the browser

@kevinansfield any further ideas?

[kevinansfield]

It's difficult to diagnose without seeing the full network history and/or error logs from web inspector (which are only available if you keep web inspector open whilst writing).

The most likely scenario for the error to occur is when there is network trouble. If one background save hits the server but the response doesn't reach the browser then you will get the error continually until you exit the editor by going to a different screen (and abandoning the post when you get the "unsaved changes" popup) or refreshing the browser.

[mordka]

I had this problem, so i debugged the error server logs, I found that clientUpdatedAt was 2 weeks older than it is on database (serverUpdatedAt). Turned out that service worker I installed on website is caching all admin pages. So that I tried to update a post with an old (cached) version, collision detection prevented it from overwriting which is excellent!
If anyone's using service worker, fixed version is here

[kevinansfield]

👍 Any sort of caching for the /ghost/* route is likely to cause the collision error or other weird problems. We always recommend that the /ghost/* route is bypassed in Cloudflare or other caches/CDNs so that you don't inadvertently serve stale data in API requests.

[adamretter]

This issue should be re-opened!

I just had the same problem today. I was editing a blog post in the Ghost desktop app (v 1.7.0) on macOS 10.13.6, and my Wifi connection dropped out several times. Eventually when saving the desktop app reported Someone else is editing.

The Ghost server is the latest version (2.2.3).

The only way I worked around this, was to open the Ghost web admin page, and copy and paste my changes to the article, save the article on the web editor. Close the web editor. Close the Ghost desktop app, then reopen the Ghost desktop app, and resume editing in the desktop app.

[kevinansfield]

my Wifi connection dropped out several times

Unfortunately this is one of the known cases that we can't handle at the moment. We'll be opening other issues later that deal with more advanced diffing and comparisons to help with the dropped connection situations.

The only way I worked around this, was to open the Ghost web admin page, and copy and paste my changes to the article, save the article on the web editor. Close the web editor. Close the Ghost desktop app, then reopen the Ghost desktop app, and resume editing in the desktop app.

You didn't need to do quite that many steps. Recovery should be as follows:

1. Copy the article contents
2. Click "Stories" in the top left then the "Leave" button
3. Click back on the story you were editing
4. Select all of the article contents and paste

If something was preventing you from doing that then there's a different issue somewhere.