#21589 closed defect (fixed)
Reverter plugin exception: IllegalArgumentException
| Reported by: | richlv | Owned by: | Upliner |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Plugin reverter | Version: | tested |
| Keywords: | template_report | Cc: |
Description
What steps will reproduce the problem?
Unsure about exact steps, but attempted to revert two changesets in a row.
What is the expected result?
No exception.
What happens instead?
Exception.
Please provide any additional information below. Attach a screenshot if possible.
URL:https://josm.openstreetmap.de/svn/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2021-11-01 23:05:46 +0100 (Mon, 01 Nov 2021) Build-Date:2021-11-01 22:25:18 Revision:18303 Relative:URL: ^/trunk Identification: JOSM/1.5 (18303 en_GB) Mac OS X 10.15.7 OS Build number: Mac OS X 10.15.7 (19H1419) Memory Usage: 2119 MB / 3641 MB (694 MB allocated, but free) Java version: 1.8.0_311-b11, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM Look and Feel: com.apple.laf.AquaLookAndFeel Screen: Display 1127230987 1920×1080 (scaling 1.00×1.00) Display 69733382 1680×1050 (scaling 1.00×1.00) Maximum Screen Size: 1920×1080 Best cursor sizes: 16×16→16×16, 32×32→32×32 System property file.encoding: UTF-8 System property sun.jnu.encoding: UTF-8 Locale info: en_GB Numbers with default locale: 1234567890 -> 1234567890 VM arguments: [-Djnlp.application.href=https://josm.openstreetmap.de/download/josm.jnlp, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlp.tk=awt, -Djnlpx.jvm=<java.home>/bin/java, -Djnlpx.splashport=-1, -Djnlpx.home=<java.home>/bin, -Djnlpx.remove=false, -Djnlpx.offline=false, -Djnlpx.relaunch=true, -Djnlpx.session.data=/var/folders/nl/flqxqsmj5q963r7tcnfrdt3c0000gn/T/session7395666964577871995, -Djnlpx.heapsize=NULL,NULL, -Djava.security.policy=file:<java.home>/lib/security/javaws.policy, -DtrustProxy=true, -Djnlpx.origFilenameArg=/Users/richlv/Library/Application Support/Oracle/Java/Deployment/cache/6.0/56/1ee8cfb8-72e8e992, -Dsun.awt.warmup=true, -Djava.security.manager] Dataset consistency test: No problems found Plugins: + HouseNumberTaggingTool (35814) + InfoMode (35543) + Mapillary (2.0.0-alpha.41) + PicLayer (1.0.1) + apache-commons (35524) + apache-http (35589) + buildings_tools (35823) + dataimport (35640) + ejml (35458) + geotools (35458) + imagery_offset_db (35640) + jaxb (35543) + jna (35662) + jts (35458) + measurement (35640) + opendata (35803) + pbf (35825) + photo_geotagging (35783) + reverter (35846) + utilsplugin2 (35842) Map paint styles: - https://josm.openstreetmap.de/josmfile?page=Styles/Coloured_Streets&zip=1 Last errors/warnings: - 31413.710 E: org.openstreetmap.josm.io.OsmApiException: ResponseCode=412, Error Header=<Precondition failed: Relation 3377631 requires the ways with id in 251754190, which either do not exist, or are not visible.> - 31413.745 E: Object still in use - <html><strong>Failed</strong> to upload <strong>relation 3377631</strong>. It refers to deleted way 251754190.<br>Please load the way, remove the reference in the relation, and upload again.<br><br>Click <strong>Prepare conflict resolution</strong> to load them now.<br>If necessary JOSM will create conflicts which you can resolve in the Conflict Resolution dialogue.</html> - 31427.620 W: Conflicts detected - <html>There was 1 conflict detected.</html> - 32214.821 W: Conflicts detected - <html>There were 2 conflicts detected.</html> - 32264.730 E: Error header: Precondition failed: Relation 3377653 requires the ways with id in 251754238,251754279,251754302,251754308,251754331,251754349,251754385,251754391,251754399,251754438,251754456,251754468,251754519,251754524,251754532,251754576,251754638,251754691,251 - 32264.864 E: org.openstreetmap.josm.io.OsmApiException: ResponseCode=412, Error Header=<Precondition failed: Relation 3377653 requires the ways with id in 251754238,251754279,251754302,251754308,251754331,251754349,251754385,251754391,251754399,251754438,251754456,251754468,251754519,251754524,251754532,251754576,251754638,251754691,251>, Error Body=<Precondition failed: Relation 3377653 requires the ways with id in 251754238,251754279,251754302,251754308,251754331,251754349,251754385,251754391,251754399,251754438,251754456,251754468,251754519,251754524,251754532,251754576,251754638,251754691,251755326,251755405,251755450,251755644,251755664,251755696,251755801,251755806,251755871,251756077,251756277,251756417, which either do not exist, or are not visible.> - 32264.873 E: Object still in use - <html><strong>Failed</strong> to upload <strong>relation 3377653</strong>. It refers to deleted ways [251, 251754238, 251754279, 251754302, 251754308, 251754331, 251754349, 251754385, 251754391, 251754399, 251754438, 251754456, 251754468, 251754519, 251754524, 251754532, 251754576, 251754638, 251754691].<br>Please load the ways, remove the reference in the relation, and upload again.<br><br>Click <strong>Prepare conflict resolution</strong> to load them now.<br>If necessary JOSM will create conflicts which you can resolve in the Conflict Resolution dialogue.</html> - 32281.717 W: Conflicts detected - <html>There were 18 conflicts detected.</html> - 32312.128 W: Conflicts detected - <html>There were 6 conflicts detected.</html> - 32313.890 E: Handled by bug report queue: java.lang.IllegalArgumentException: version > 0 expected. Got 0 === REPORTED CRASH DATA === BugReportExceptionHandler#handleException: No data collected. Warning issued by: BugReportExceptionHandler#handleException === STACK TRACE === Thread: AWT-EventQueue-2 (31) of javawsApplicationThreadGroup java.lang.IllegalArgumentException: version > 0 expected. Got 0 at org.openstreetmap.josm.data.osm.OsmPrimitive.setOsmId(OsmPrimitive.java:245) at reverter.DataSetCommandMerger.mergePrimitive(DataSetCommandMerger.java:84) at reverter.DataSetCommandMerger.mergeWay(DataSetCommandMerger.java:134) at reverter.DataSetCommandMerger.merge(DataSetCommandMerger.java:196) at reverter.DataSetCommandMerger.<init>(DataSetCommandMerger.java:51) at reverter.ChangesetReverter.getCommands(ChangesetReverter.java:393) at reverter.RevertChangesetTask.revertChangeset(RevertChangesetTask.java:169) at reverter.RevertChangesetTask.realRun(RevertChangesetTask.java:93) at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:94) at org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:142) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
Attachments (1)
Change History (19)
comment:1 by , 3 years ago
| Summary: | Revverter plugin exception: IllegalArgumentException → Reverter plugin exception: IllegalArgumentException |
|---|
comment:2 by , 3 years ago
comment:3 by , 3 years ago
If I recall correctly, they were 114073708 and 114073790, "Revert changeset fully" was set.
comment:4 by , 3 years ago
I cannot reproduce the problem. Maybe one or more objects in those changesets were changed again. I fear we have to wait until this happens again.
follow-up: 7 comment:5 by , 3 years ago
Luckily, still reproducible for me.
- Fully revert 114073708.
- Confirm the two conflicts.
- Fully revert 114073790.
- Exception.
comment:6 by , 3 years ago
Ah, I only tried both cs together so that reverter can choose the correct order. Your steps force the wrong order.
I can reproduce now. Please give me a few days to find out what's wrong...
comment:7 by , 3 years ago
Replying to richlv:
Luckily, still reproducible for me.
- Fully revert 114073708.
- Confirm the two conflicts.
- Fully revert 114073790.
- Exception.
I guess you need to solve the conflicts. I remember problems when reverting in the wrong order (older first and than younger), which in my eyes makes no sense.
comment:8 by , 3 years ago
Well, the expected usage is to tell reverter both cs, but it should not crash when the user tries a different way. Maybe reverter should simply reject to revert data in a layer that has conflicts.
comment:9 by , 3 years ago
Solving the confllicts to "my version" doesn't prevent the crash. After reverting 114073708 you have some relations with members like https://www.openstreetmap.org/way/251754391 and these cause new conflicts.
Some ideas:
- detect that reverter was already executed for an older changeset in the target layer and reject this action with a notification that tells the user to revert the cs in the right order or all at once.
- try to fix the merge logic to do something that doesn't result in a crash. Don't know for sure what the result should be.
comment:10 by , 3 years ago
Keep it simple and teach the user the logic of reverting from younger past to stone age (2004).
The problem are the incomplete and deleted members. E.g. downloading all incomplete members after reverting the first cs and solving the two conflicts, I get 30 more conflicts about deleted ways. Undeleting these ways and then reverting the younger CS 114073790 works without exception.
Looking at resources this is really bad practice as undeleting manually instead of reverting CS 114073790 first results in single history requests for each way and each of its nodes
comment:11 by , 3 years ago
Hmm, I still have no good idea how to handle this. It's quite difficult to keep track of reverted CS per layer. Have to manage undo/redo and layer merges, so this probably just adds more complexity. For sure it is not simple.
BTW: the logic that adds the changeset tag like created_by=reverter_plugin/35846;JOSM/1.5 (18324 SVN en) also doesn't work with merged layers.
Also, it may work well to revert a newer CS after an older one if they are not related.
My best solution so far is to cancel the revert action if new conflicts are found and ask the user to solve them first:
Please solve conflicts and maybe try again to revert.
by , 3 years ago
| Attachment: | 21589.patch added |
|---|
stop if missing objects caused conflicts, replace tabs
comment:12 by , 3 years ago
For the general problem of remaining conflicts see #18461. From time to time I also face #8660.
I am not sure anymore, if this is not a general problem with DataMerger, see also #20006 and #20904.
E.g. What happens if you revert both CS in different layers and merge them? Why do we get problems/conflicts with the deleted members, while the second revert does exactly the task?
comment:13 by , 3 years ago
I think this is caused by the changes in r17341. The reverter plugin stumbles over those new conflicts :(
I still try to understand where this has to be fixed (reverter or core)...
comment:15 by , 3 years ago
Replying to GerdP:
Maybe we should simply not allow reverts in layers which already contain data.
What is the difference to reverting selection to a new layer and then merging the layers (#20006)? We still end up with two layers with modifications and possible incomplete data (members) which are merged, right?
comment:16 by , 3 years ago
The difficulty is that reverter implements its own merger (which creates commands), but also depends on the core merger when missing data is downloaded. A non-empty layer simply adds complexity, as it may contain all kinds of special cases.
comment:17 by , 3 years ago
Mmh, this would make it really difficult to revert in correct order step by step.
First, I thought that is ok, now I am undecided and have to think about it.
comment:18 by , 3 years ago
The main problem is to find all changesets that have to be reverted. Once you have this list you can execute reverter for the complete list (in any order) and there should be no conflicts.
For the given example I would use this list (order is not correct): 114073790 114073708 114073902 114073727 114073955
Please tell us at least the ids of the changessets and what options you used in the reverter dialog.