Wiki writes every edit action to the server which might fail for any number of reasons. Wiki diverts the editing to browser local storage, but not without annotating the action with what went wrong.
Here is an error I got while alphabetizing Workflows.
{ "type": "move", "order": [ "3cee1803b52b90e5", "d1e60683b61a3fbe", "e27c44e4db5b4d8d" ], "id": "d1e60683b61a3fbe", "date": 1418910738287, "error": { "type": "error", "msg": "Internal Server Error", "response": "Server Ignoring move. Try reload." } }
There was a time where server errors flashed at the top of the screen. The server messaging must date back to then. Let's find that in the source. github 
when 'move' action.order.map (id) -> page.story.filter((para) -> id == para.id )[0] or throw('Ignoring move. Try reload.')
This is the server code that interprets the action. It says, to 'move' take the page.story and rearrange items to match the action.order. It expects to find each item in the story but if it doesn't it throws an error.
Network delays over long distances interfere with wiki client-server synchronization. The errors we report here occurred in Singapore when editing in Portland.
The client and the server are out of sync. How does the user forge ahead? The server suggests a reload. That would sync the client to the server. Our practice now is to save the edit and then 'fork' the whole page back to the server which regains sync with what the user wanted, not what the server had.
You can find this history. Click the first move in the journal for Workflows. This returns to the very moment of the error. Double-click the timestamp of that version to see action as the json object shown above.