Ghost: "Someone else is editing" errors when no-one else is editing
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_atfield - Server handles/responds to the second request which at this point has an old
updated_atvalue 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 (https://github.com/TryGhost/Ghost-Admin/pull/901)
- the new save task will be in addition to the current
savetask because the current task has additional publishing workflow requirements that the PSM inputs skip - the new save task will be part of the
saveTasksgroup so that all save requests are queued to prevent collision errors
- the new save task will be in addition to the current
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 20 (12 by maintainers)
Commits related to this issue
- Debug: Update Collision refs #8969 - we would like to figure out how often people get the error and with which context — committed to kirrg001/Ghost by kirrg001 7 years ago
- Debug: Update Collision (#9103) refs #8969 - we would like to figure out how often people get the error and with which context — committed to TryGhost/Ghost by kirrg001 7 years ago
- 🐛 Fixed "Someone else is editing" errors showing when no-one else is editing closes https://github.com/TryGhost/Ghost/issues/8969 Collision detection errors were appearing incorrectly because the s... — committed to kevinansfield/Ghost-Admin by kevinansfield 7 years ago
- 🐛 Fixed "Someone else is editing" errors showing when no-one else is editing (#901) closes https://github.com/TryGhost/Ghost/issues/8969 Collision detection errors were appearing incorrectly beca... — committed to TryGhost/Admin by kevinansfield 7 years ago
Hi folks, Possibly a new issue, but just had this again in Ghost 5.0!
👍 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.I had this problem, so i debugged the error server logs, I found that
clientUpdatedAtwas 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🤞 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