Server trips over unexpected move actions.

[WardCunningham]

We've seen items in a story get nulled out when the client and server disagree about story item IDs. Here is a simple way to demo this failure:

1. search for some popular word
2. move an item in the search result

This fails because the search result doesn't exist on the server. It fails in a different way when it does exist.

A quick fix would be to disable moves for ghost pages. We should do this and more. But we should also take a deep look at how move actions are processed on the server. Here is another scenario likely to cause problems.

1. open a page in two separate browsers
2. add a paragraph in one browser
3. move a paragraph in the other browser

Here we expect the new paragraph will be lost or otherwise miss handled.

[rynomad]

Confirm lost paragraph in your problem scenario. Doesn't seem as likely to happen in practice even with two users visiting the page at the same time because they wouldn't both be logged in, but still troublesome. would handling the different actions as seperate put items help in any fashion? or maybe farm.page_get/put real quick before executing the move to make sure that the server is modifying the 100% current version of the page rather than the cached version which, in case above doesn't have the new paragraph and so put's down a new page w/o the intermediate edit? If there was a way to push a page back to all connected clients immediately after an edit, that could be mighty handy but perhaps that's just a naive notion from a newb.

[WardCunningham]

Commit 9f0bbec656b26fefaeca08465e3e44544d9193ff adds a server-side check for this problem and fails with a non-destructive error.

The scenario I describe above does not require a separate browser to elicit the failure. It is sufficient to edit a page from two different tabs. This situation should be detected and reasonable alternatives for going forward presented. One possibility is to fail the edit and then have that save the edit in browser local storage so that the edits can be resolved.

Issue #342 presents similar needs to save content while resolving failed or destructive operations. It would be great if they (and any more if there are others) could be handled with similar mechanisms.