Cancel upload produces a mess :)

[mrjones]

What steps will reproduce the problem?

1. Make changes
2. Click upload
3. Press cancel in the middle of the upload

What is the expected result?

Not to have uploaded anything to the OSM database.

What happens instead?

It uploaded half of the data (data up to the cancellation point) and when trying to upload again it shows a lot of conflicts.

Please provide any additional information below. Attach a screenshot if possible.

I am not sure if I am missing something when cancelling an upload. I am not familiar with the DB itself or the methods for updating it, but I would expect a rollback of the uploaded changes in case of cancel. And a commit otherwise..

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-11-06 20:18:38 +0100 (Sun, 06 Nov 2016)
Build-Date:2016-11-06 21:45:03
Revision:11223
Relative:URL: ^/trunk

Identification: JOSM/1.5 (11223 en) Windows 10 64-Bit
Memory Usage: 848 MB / 910 MB (65 MB allocated, but free)
Java version: 1.8.0_111-b14, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1366x768
Maximum Screen Size: 1366x768
Dataset consistency test: No problems found

Plugins:
+ AddrInterpolation (33005)
+ DxfImport (1008)
+ FastDraw (33004)
+ FixAddresses (33004)
+ HouseNumberTaggingTool (32699)
+ Mapillary (v1.3.2)
+ PicLayer (33088)
+ apache-commons (32994)
+ apache-http (32699)
+ buildings_tools (33004)
+ ejml (32680)
+ ext_tools (33004)
+ geotools (33042)
+ importvec (33088)
+ jts (32699)
+ opendata (33088)
+ turnrestrictions (33088)
+ utilsplugin2 (33088)

Tagging presets:
+ http://maps.openstreetmap.ie/josm/irishboundaries.xml

Map paint styles:
+ https://josm.openstreetmap.de/josmfile?page=Styles/AddressValidator&zip=1
+ %UserProfile%\Pictures\Screenshots\townland.mapcss

Last errors/warnings:
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet

[stoecker]

That's nothing we can change. The API has no transaction control like SQL databases. If you abort in the middle of an upload you will get an half-uploaded state always.

You can reduce the issues when you use the feature to redownload the current datasets, which gets the partial upload from the server and merges it with the current dataset.

[LeTopographeFou]

Hi,

Sorry but I don't agree with the resolution and the closed status. I've already been surprised after Canceling to see that there is no cancelation at all (which is a poor UI design IMHO). Anyone can create a big mess whithout ever knowing of the consequences.

I think that we can either:

• Remove the cancel button (=> it gives the impression that you can cancel which is wrong). No button and only a progress bar means that you can't go back.
• Replace Cancel by Stop or Halt or something else and add a message to say that half of the data have been comitted. Bonus: display the list of the modifications which have been commited in order for a user to fix it by himself. You can also put the progress bar and checkmarks in the commit window (the one where you can see modifications and type a comment and sources)
• Probably more touchy: Revert the committed data on JOSM side (and not on OSM side, as if I click Edit > Cancel until I reach the original state) and then commit again.

Thank you for all the hard (but good!) work done in JOSM!

[maarten]

An option is also to make either an automated rollback of the changeset immediately after uploading, or send a message to whereever people are active to revert changesets.

[LeTopographeFou]

Yes but as @stoecker explained rollback is not supported natively, thus the third option which consist of rollbacking by using the local history of actions and then commit either manually or automatically.

Otherwise in short term option 1 or 2 of my post (depending of the philosophy of the development team) can be easily put in place in order to prevent more errors. I recommend to implement one of those before trying to implement any complexe rollback mechanism.

[mmd]

As soon as the upload request has reached the server, there's no way to stop processing from JOSM side. The API will apply all changes in a transactional manner, meaning it's an all or nothing update. There's no such thing as an "half-uploaded" state. Now with chunking in JOSM, it means that each chunk is either applied completely, or not at all.

[anonymous]

I see two further options:

• Use the reverter plugin and re-upload the changes.
• JOSM should keep track of what was uploaded and don't upload that again. I mean, that happens anyway when you do a full upload, there just has to be a proper administration of uploaded objects also when cancel has been pressed.

[edit] comment by maarten