Opened 11 years ago

Closed 7 years ago

#2374 closed defect (fixed)

Potlatch sometimes uploads duplicates ways (and presumably nodes/relations) after API 0.6 when creating new objects

Reported by: avar Owned by: richard@…
Priority: major Milestone:
Component: potlatch (flash editor) Version:
Keywords: ban_avar Cc:


(This has more to do with amf_controller.rb than Potlatch proper so putting it in the website component)

See e.g.:

(deleted now)

Presumably this happens like this:

  1. Potlatch saves a new way (or node/relation) to the server
  2. The server accepts it & writes it to the data but times out, doesn't reply
  3. Potlatch gets tired of waiting/doesn't get a reply. Tries again
  4. A duplicate way is created

Perhaps this could be worked around like this:

  1. If Potlatch tries to save an object but isn't successful add it to a list of suspect objects on the client-side
  2. Poll the server to see if those objects were really created
  3. If not, save again

Or on the client/server side:

I'm not sure but it looks like Potlatch gives the ID "0" to all new objects. Perhaps if it gave unique negative IDs to all objects those IDs could be tracked on a per-changeset basis on the server side. If an ID comes up again from the client indicate that he's submitting a duplicate.

Change History (4)

comment:1 Changed 11 years ago by Tom Hughes

Component: websitepotlatch (flash editor)
Owner: changed from Tom Hughes to richard@…

I'm not convinced this is going to be down to timeouts - potlatch edits are normally small so don't take long to apply.

comment:2 Changed 11 years ago by Richard

Keywords: ban_avar added; ban_potlatch removed

IME the "operation completed but no response received from server" scenario is most common when updating large objects, typically long route relations. If it happens with a small object, it's usually the result of a connection failure somewhere between Potlatch (the SWF) and OSM.

Potlatch doesn't give the id 0 to new objects. It gives unique negative ids as about five seconds' use should tell you. :) Otherwise, how would it cope with a closed way, where the same node occurs twice?

Per-changeset storage would be one way of storing this but I'm not aware of any way of doing that, other than something really hacky like serialising into (presumably a set of) temporary tags that are deleted on changeset close.

As a point of order, on point 3, Potlatch doesn't try again unless you expressly tell it to.

I think the real answer is to boot t@h et al off the server and use it for editors only. ;)

comment:3 Changed 11 years ago by Richard

I've committed a change to amf_controller that now streams the response to all AMF calls as they're done, rather than assembling the responses into a big array and sending once all the calls are done. If you open up Activity Monitor in Safari, or whatever your browser's equivalent is, you can see the data start to stream through. (So Potlatch now has the only streaming part of the API. ;) )

One of the advantages of this is that the six-byte response header is written immediately by amf_controller... acting like an initial Keep-Alive, almost.

So I'd be interested to see whether this might help to address the "operation completed but no response received from server" issue.

comment:4 Changed 7 years ago by iandees

Resolution: fixed
Status: newclosed

Cleaning aging tickets.

Note: See TracTickets for help on using tickets.