I have 92 changes that I want to save. I have tried several times, in which the process gets stuck in a loop while displaying ‘checking for conflicts’, and going through a counter. Heavy internet-traffic is visible.
I had to shut the tab in Firefox to escape.
When opening a new tab, the changes are restored.
It seems related to getting confronted a couple of times with a rate limit, which must have been the result of a stupid blockade.
Meanwhile, I worry there might actually be conflicts, as the process has taken too long.
Does anyone know how to break this cycle?
I tried opening the edit in a different browser, but the changes are not known there, because apparently bound to the browser I edited in.
Giving you this advice regardless of the block: instead of trying to upload, save to an osmChange / OSC file (there’s a link to do that in the same panel).
You can later load the edits back in to iD or an other editor of choice.
Putting this very bluntly, since you’ve adopted the persona of a mule:
If you’re finding yourself subject to repeated blocks because you’re repeating the same problematic activity then frankly it’s not the blocks that are stupid. You need to address that issue before worrying about “uploads stuck in a loop”.
While it might have the same cause, iD should still not loop in such a situation and that is actually different than the behaviour I reported at the time (obviously iD from today is very different than iD years ago so who knows what is going on).
A neverending spinner is probably indicative of a merge conflict. iD normally handles merge conflicts automatically, but sometimes it gets confused. I normally run into this when iD successfully uploads the changeset, fails to get a successful response from the server for whatever reason, lets me try uploading again, and immediately runs into a ton of conflicts even though there’s actually nothing left to upload. If this user is blocked, then it would be a different scenario, but maybe somehow related.
That stupid blockade had already finished. And I had already sucsessfully committed a changeset, though stalled by the apparent very unpractical implications of that blockade by a rate-limit.
A second set repeatedly both was stalled and failed by going into that loop.
That loop is a problem on itself, and may also be triggered by merge-conflicts.
I will try again and also attempt to store like suggested.