[Potlatch-dev] Conflict and error handling - work in progress
Richard Fairhurst
richard at systemeD.net
Sun Dec 12 23:54:27 GMT 2010
Hi all,
I've committed some work-in-progress code that deals sensibly with
errors returned by the API when saving, instead of just saying "oh crap"
and blowing up. It's in r24725.
As usual this e-mail is partly documentation, partly aide-memoire. Two
things in particular to note:
- it's not finished; the skeleton's there but not all error situations
are dealt with yet
- a minor API change is required to support this
The API change is because an app running under Flash Player can't read
an HTTP response body _unless_ the response code is 200 OK. The OSM API
(quite properly) sends a response code appropriate to the error that
occurred, with the details in the body. For example, OSM might send "400
Bad Request" with the body "Element Way/2783 has duplicate tags with key
highway". But all P2 would see is "400 Bad Request", which isn't much
use for finding out what the error was.
So we, regrettably, need an API change where P2 sends a header saying
"I'm a broken client and can't read error bodies" and the API says "tsk,
ok, I'll send an error code and description under a 200 OK".
The commit works against a little patch which I've put at
http://wiki.openstreetmap.org/wiki/User:Richard/notes . I believe Tom's
thinking of doing a proper XML error response so we'll need to trivially
patch the relevant code in XMLConnection.as to reflect this.
(Incidentally, there's another tiny API patch required to support
r24664, which is something endemic to online editors and which P1 once
suffered from, too. But that's another story.)
When the API sends back an error, assuming P2 can read it, the following
now happens:
- XMLConnection.as parses the response (diffUploadAPIError)
- It calls the relevant "throw error" method (in the Connection base class)
- The throw method dispatches an Error event, which comprises a message
plus callback methods for each option available to the user (e.g.
"retry", "cancel")
- The application (potlatch2.mxml) picks up the Error event via a
listener, and displays an alert
- When the user clicks a button in the alert, the relevant callback
method is called
All of this is done apart from two of the callback methods. One is the
method to start a new changeset and retry the upload (if the old
changeset has broken for some reason). To implement this we'll need to
move a little bit of logic from SaveDialog to Connection.
The second is the one to revert a conflicting entity to the current
server version, then retry. To implement this we'll need to support
single-entity GETs from the API.
So with a bit more work, and these two little API patches, we should
have nailed down the "P2 wouldn't save and lost my work" problem. Sadly
I won't have a whole lot of time over the next fortnight, but if anyone
wants to pick this up...
cheers
Richard
More information about the Potlatch-dev
mailing list