[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