"Someone else is editing" errors when no-one else is editing #8969

kevinansfield · 2017-09-04T09:53:22Z

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:

First save request is fired by the admin client and the server handling/response is delayed for some reason
A second save request is fired (this could be through Cmd-S, an autosave, or editing a PSM field)
Server handles/responds to the first request, updating the updated_at field
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:

Open a post in the editor
Switch to "Slow 3G" throttling in Web Inspector
Make a change to the post body
Fairly quickly open the PSM then check the "feature" or "page" checkboxes
🤞 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

evaluate debug logs
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 (🐛 Fixed "Someone else is editing" errors showing when no-one else is editing Admin#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

The text was updated successfully, but these errors were encountered:

kevinansfield · 2017-09-04T09:59:52Z

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 · 2017-09-21T13:29:19Z

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 · 2017-09-21T13:34:30Z

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 · 2017-09-28T10:58:55Z

@dkbast I am unable to reproduce 😔

stefanovazzocell · 2017-09-29T03:45:51Z

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 · 2017-10-02T13:52:35Z

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

stefanovazzocell · 2017-10-02T15:09:09Z

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 · 2017-10-02T15:39:07Z

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 👍

refs TryGhost#8969 - we would like to figure out how often people get the error and with which context

refs #8969 - we would like to figure out how often people get the error and with which context

kirrg001 · 2017-10-30T10:32:14Z

I've added a subtask on top.

[ ] evaluate debug logs

kevinansfield · 2017-11-01T15:58:41Z

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.

…editing closes TryGhost/Ghost#8969 Collision detection errors were appearing incorrectly because the save routines in the post settings menu bypass the sequential saves in the main editor controller and so are prone to having stale data if a previous save is still in progress. - added a new `savePost` task that is part of the `saveTasks` group so that all post saves are sequential - pass the `savePost` task to the `{{gh-post-settings-menu}}` component - use `savePost` task in `gh-post-settings-menu` instead of calling `save()` directly on the model instance

…editing (#901) closes TryGhost/Ghost#8969 Collision detection errors were appearing incorrectly because the save routines in the post settings menu bypass the sequential saves in the main editor controller and so are prone to having stale data if a previous save is still in progress. - added a new `savePost` task that is part of the `saveTasks` group so that all post saves are sequential - pass the `savePost` task to the `{{gh-post-settings-menu}}` component - use `savePost` task in `gh-post-settings-menu` instead of calling `save()` directly on the model instance

kevinansfield · 2017-11-02T09:51:16Z

🤞 the false positive collision detections are all resolved with TryGhost/Admin#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 · 2018-04-08T14:01:54Z

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 · 2018-04-08T16:41:22Z

@chrissainty Thanks, that would be super helpful!

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

@kevinansfield any further ideas?

kevinansfield · 2018-04-09T12:58:53Z

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 · 2018-04-15T11:51:56Z

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 · 2018-04-16T09:45:37Z

👍 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 · 2018-10-18T08:20:21Z

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 · 2018-10-18T08:54:20Z

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:

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

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

thecadams · 2022-05-25T07:39:28Z

Hi folks,
Possibly a new issue, but just had this again in Ghost 5.0!

jeandcc-gg · 2022-05-30T14:43:57Z

Just had this and I'm on Ghost 4.48

kirrg001 added the needs:info [triage] Blocked on missing information label Sep 4, 2017

kirrg001 assigned kirrg001 and kevinansfield Sep 4, 2017

kirrg001 added a commit to kirrg001/Ghost that referenced this issue Oct 5, 2017

Debug: Update Collision

0461029

refs TryGhost#8969 - we would like to figure out how often people get the error and with which context

kirrg001 mentioned this issue Oct 5, 2017

Debug: Update Collision #9103

Merged

kevinansfield pushed a commit that referenced this issue Oct 5, 2017

Debug: Update Collision (#9103)

30e790b

refs #8969 - we would like to figure out how often people get the error and with which context

kevinansfield mentioned this issue Nov 1, 2017

🐛 Fixed "Someone else is editing" errors showing when no-one else is editing TryGhost/Admin#901

Merged

kevinansfield added in review and removed needs:info [triage] Blocked on missing information labels Nov 1, 2017

kevinansfield closed this as completed in TryGhost/Admin#901 Nov 2, 2017

kevinansfield added bug [triage] something behaving unexpectedly and removed in review labels Nov 2, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

"Someone else is editing" errors when no-one else is editing #8969

"Someone else is editing" errors when no-one else is editing #8969

kevinansfield commented Sep 4, 2017 •

edited

Loading

kevinansfield commented Sep 4, 2017

dkbast commented Sep 21, 2017

kirrg001 commented Sep 21, 2017

kirrg001 commented Sep 28, 2017

stefanovazzocell commented Sep 29, 2017 •

edited

Loading

kirrg001 commented Oct 2, 2017

stefanovazzocell commented Oct 2, 2017

kirrg001 commented Oct 2, 2017

kirrg001 commented Oct 30, 2017

kevinansfield commented Nov 1, 2017

kevinansfield commented Nov 2, 2017

chrissainty commented Apr 8, 2018 •

edited

Loading

kirrg001 commented Apr 8, 2018

kevinansfield commented Apr 9, 2018

mordka commented Apr 15, 2018 •

edited

Loading

kevinansfield commented Apr 16, 2018

adamretter commented Oct 18, 2018

kevinansfield commented Oct 18, 2018

thecadams commented May 25, 2022

jeandcc-gg commented May 30, 2022

"Someone else is editing" errors when no-one else is editing #8969

"Someone else is editing" errors when no-one else is editing #8969

Comments

kevinansfield commented Sep 4, 2017 • edited Loading

Issue Summary

Reproduction steps

TODO

kevinansfield commented Sep 4, 2017

dkbast commented Sep 21, 2017

kirrg001 commented Sep 21, 2017

kirrg001 commented Sep 28, 2017

stefanovazzocell commented Sep 29, 2017 • edited Loading

kirrg001 commented Oct 2, 2017

stefanovazzocell commented Oct 2, 2017

kirrg001 commented Oct 2, 2017

kirrg001 commented Oct 30, 2017

kevinansfield commented Nov 1, 2017

kevinansfield commented Nov 2, 2017

chrissainty commented Apr 8, 2018 • edited Loading

kirrg001 commented Apr 8, 2018

kevinansfield commented Apr 9, 2018

mordka commented Apr 15, 2018 • edited Loading

kevinansfield commented Apr 16, 2018

adamretter commented Oct 18, 2018

kevinansfield commented Oct 18, 2018

thecadams commented May 25, 2022

jeandcc-gg commented May 30, 2022

kevinansfield commented Sep 4, 2017 •

edited

Loading

stefanovazzocell commented Sep 29, 2017 •

edited

Loading

chrissainty commented Apr 8, 2018 •

edited

Loading

mordka commented Apr 15, 2018 •

edited

Loading