Opened 16 years ago
Closed 16 years ago
#1953 closed defect (worksforme)
Changes lost during upload break (abort or server error)
| Reported by: | anonymous | Owned by: | framm |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | Core | Version: | latest |
| Keywords: | undo list erase to early | Cc: |
Description
JOSM v1181.
Found because today the OSM servers have been a little slow; JOSM is timing out, eg.
upload to: http://www.openstreetmap.org/api/0.5/way/16478150... timed out, retries left: 10
If the upload is then cancelled by pressing "[Cancel]", then that one change that was being uploaded is marked as sent (there after "No changes to upload"), when in fact the change hasn't been confirmed as sent.
As it is marked as already-sent, JOSM will not attempt to upload that one change again and it gets lost.
Attachments (0)
Change History (6)
comment:1 by , 16 years ago
| Keywords: | undo list erase to early added |
|---|---|
| Summary: | If a timing-out upload is manually cancelled, JOSM marks the change as sent → changes list cleared too early, only maintained internally |
comment:2 by , 16 years ago
Hasienda: That is on purpose. Tracking down which changes affect which objects and partly clearing the history would be impossiblke for some changes and very complicated for others.
Thought I think that is another problem as the one of original report.
comment:3 by , 16 years ago
| Summary: | changes list cleared too early, only maintained internally → Changes lost during upload abort |
|---|
comment:4 by , 16 years ago
| Summary: | Changes lost during upload abort → Changes lost during upload break (abort or server error) |
|---|
Actually the same happens without abort, when a server error occurs. Always the first change is lost.
comment:6 by , 16 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
This is old, related to former API 0.5 times. In current API 0.6 doesn't occur anymore. Closing.
Please reopen if still relevant.
JOSM revision 1206
Today there was (another) interruption of server API, making upload timing-out. I canceled manually. All changes where cleared from the list. But I left JOSM open and was able to upload all changes hours later, despite there was an empty changes window in JOSM before the later retries. Again, upload was successful and lossless, partly undo of latest changes was no longer possible after first timeout/cancel action.
So it seems more like a GUI problem to me. JOSM knows about the unsaved changes quite well all the time, but cleans the actions from the main window on <Cancel> too early.