Endless conflict check loop following conflict resolution save failure

[mikini]

Like #5114 and #7163 I also encountered an endless loop today in conflict checking on a locally deleted entity that had been updated on the remote.

This was on the current OSM production iD 2.17.0.

During the original save I was presented with the conflict resolution dialogue on a way modified both locally and remotely (both were fixes to overlap in outline of way 760017529 v1). In the dialogue I was not able to click "Save" after choosing to keep "theirs". The button was blue and seemed active visually but to my recollection didn't react on hover and nothing happened on mousedown.

After multiple failed attempts aborting and repeating the save with no other result I went back to editing mode removing the conflicting way locally in the hopes of then being able to save the changeset of my day-long editing session (sad but true). Saving now didn't trigger the resolution dialog but ended up in the endless "Checking conflicts" loop repeatedly counting from 0 to 1246.

In retrospect I should have saved the OsmChange representation of the changes before deleting the way and had a look at my script modifiers to see if they interfered with the conflict resolution (they usually don't interfere with iD); uMatrix, uBlock Origin and Decentral Eyes.

I left the conflict check for about an hour until I started poking at it again. Looking at Firefox's javascript console revealed 3 occurrences of graph.entities[n.id] is undefined (see screenshot below, locale is Danish).

These seem to originate from segmentWasEdited() (from svgLines::drawTargets) at line 72580 in asset (also see screenshot below).

Looking at the debugger didn't give further hints (I'm not that familiar with javascript debugging so didn't dare experimenting with breaking the execution with my changeset dangling in there).

I do have a screen capture with some browsing through the Developer Tools if you reckon I might have captured anything useful.

I had a look through Storage to see if I might be able to extract anything useful of my changes, but didn't see much to the liking (see screenshot below). Shouldn't the complete edits be stored here? Could some sort of dump have been done from the dev tools to secure the changes in this situation? I have rather good experience with the contingency of iD's edited data on normal browser shutdowns/restarts etc. but this time there were sadly no trace of a previous session when restarting iD except from the changeset comment (key=comment) which was still visible in Local Storage and the save dialogue after reload.

Console with TypeError:

Code of segmentWasEdited() in deployed asset:

Local Storage contents during loop:

[Thorwynn]

Can't help with the bug but iirc when this happened to me I restarted browser, reloaded my edits, clicked save, then clicked "Download osmChange file" on bottom left. Was able to save my changes as an *.osc file then load it into JOSM which has more detailed conflict resolution.

[aseques]

Same thing happened to me today, don't know how to diagnose it, but I downloaded the osc file in case it's useful.
My feeling is that it seems something related to firefox support, but I cannot guess any further.
changes.osc.txt

[mikini]

Hit this again with iD 2.19.5 on the production site.

The conflict was on way 366250882 with "outer" role of relation 5806748. I was prompted to choose between "Theirs" or "Mine" (or maybe it was "Yours"). I chose "Theirs" this time being able to click "Save" but still ending up in the "checking conflicts" loop.

This time the javascript console didn't contain any type warnings as in the issue's original incident:

[Kovirii]

Extremely annoying. Happened to me, apparently I left the editor sit open overnight, started editing (202 changes) and it grabbed stale data(???) and after trying a couple of attempts to resolve the conflict it got stuck in the loop. It's continuously querying OSM and trying to upload but receiving a 409 error. The conflict was that another user had deleted and recreated a road using Potlatch. I tried to restore the road initially (before getting stuck in a loop) and it failed, giving the error that a required node did not exist. It's currently still running, is there specific debug info I ought to grab? I had to inspect element to reach the link to download the changes file blob. Conflicting changeset here.

[Kovirii]

Even worse, if you leave/don't save edits from the conflict resolution page, they are already deleted from the local cache (where they are saved in case of crashes) so reloading the page will not restore them. The cache should absolutely not be deleted until it's confirmed the changeset has been uploaded successfully.

[mikini]

This is really annoying, yes, but hopefully not that common. At least the pattern of use has a lot to say about the probability (long editing session -> high probability of conflict -> high probability of this happening). From what I gather of the other issues opened about this, the local storage backup is not always cleared. I have, however, always had the edit gone MIA from the local storage.

But thanks @Kovirii, for the hint that the osmChange (.osc) file can be accessed through the object inspector, this also made it possible for me to rescue my edit from the stuck JS application.

For others experiencing this, the procedure is;

• enter your browser's "Inspector" tool (in Firefox: Menu->Tools->Web Developer->Inspector or shift+ctrl+c)
• find the "a" element with class "download-changes", it has the CSS Path; "html body div#id-container.ideditor.mode-save div.sidebar div.sidebar-component div.body div.modal-section.commit-changes-section div.section.section-changes-list div.disclosure-wrap.disclosure-wrap-changes_list div.commit-section a.download-changes" (in Firefox: searching for "a.download-changes" will open the tree and select it directly)
• hover over the a element's "href" attribute with "blob:" URL
• right click and select "Open Link in New Tab", this will open a new tab containing the osmChange file contents
• save the page (Firefox: Menu->File->Save Page As or context menu) with .osc extension (Firefox will default to .xml)

Screenshot of the Inspector's context menu after searching with Firefox:

[boothym]

A similar thing happened to me when I was editing a relation with 5000+ members. Both sides of the 1,000 of 10,000 counter just kept going up and Firefox was using a lot more CPU than normal. There was no end in sight so I had to close the tab.

Fortunately, the first time I pressed save it I was presented with a box containing html code of an http error, so I then downloaded my changes for use in JOSM before trying again a few times.

[kristianrl]

I'm experiencing the same issue - is there any way to debug what is causing the issue (Uploader ændringer til OpenStreetMap... Kontrollerer konflikter: 207 ud af 225). I can reload the page, make more changes, and the number changes.

Is there any way to figure out what "conflict 207" covers? I'd then be able to remove that causing change from my changeset and retry.

[boothym]

@kristianrl not sure how to debug it in the browser, but perhaps you could download changes.osc at the bottom of the sidebar, load it into JOSM and then see what conflicts occur when you try to upload it?

[mikini]

@kristianrl If the conflict counter actually halts (at change 207 or any other) I would say you experience a different issue than the one described here (I'm the original poster). This issue regards a repeated (probably endless) loop over the changes in the change set where the count is just reset to 0 when it reaches maximum.

I perceive the count as being an iteration over the actual objects (nodes, ways, relations) that has changed during the edit, checking whether the object has been modified on the server since it was originally downloaded by iD. So as such fx. 207 doesn't mean anything other than being the 207th object your edit has touched (in some order determined by iD's specific implementation of the conflict resolution algorithm).

I guess you would be able to inspect a specific change in the developer tools of your browser given enough insight in iD's internals. An easier option would probably be, as suggested, to download the change set as an .osc file and attempt upload/conflict resolution in another editor (JOSM is a good choice).

[rivermont]

This is still occurring.
If your changeset is over the browser cache and this loop happens, an interesting workaround is to cut the internet connection which will allow you to download the OSM change file to upload through JOSM.

[Helium314]

This still happens, and even after manually solving the conflict (undoing the "bad" edit) the endless loop remains.
Reloading the page and restoring the edits does not help. But interestingly after reloading, the previously conflicting way is in an "incorrect" state, i.e. not what it was before the edits, not the current state, and not a state it ever was in while I did the edits.

If your changeset is over the browser cache and this loop happens, an interesting workaround is to cut the internet connection which will allow you to download the OSM change file to upload through JOSM.

Unfortunately does not work for me...

[k-yle]

today i got a different error which was a bit weird:

[gy-mate]

I think today I got the same error as @k-yle:

Screen.Recording.2024-10-13.at.23.26.11_lowbitrate.mp4

I clicked on Upload when several ways in the change had conflicts. But the progress count in the popup flickered between 0 and 77 and didn't make any real progress, only got 409 error codes from the API. So I had to download the OsmChange file, switch to JOSM, then resolve the conflicts there manually.

[cicku]

I encounted this issue when trying to save a changeset of 400+changes.

I would suggest adding a feature to prevent infinite loop so I can save my changes to a local file, instead of losing half of the edits after refreshing the screen.