-
-
Notifications
You must be signed in to change notification settings - Fork 353
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rapid undo failed #1433
Comments
Could you try to reproduce it, looking at the log? Iirc it is logged if a change is not applied due to a conflict
…On June 20, 2019 9:46:31 AM GMT+02:00, Mateusz Konieczny ***@***.***> wrote:
During testing #1432 I made a test edit in a live OSM database that I
immediately reverted[1]. To my surprise revert was not actually applied
- see history of https://www.openstreetmap.org/way/22766359/history
For example https://www.openstreetmap.org/changeset/71430814 contains
test edit adding access tag, revert edit was not applied. Selecting
"undo" again was showing toast that nothing more can be undone.
It may be caused by competing edits and undos applied to the same some
object in a short time, I am not considering likely that #1432 code is
buggy.
[1] not the optimal way of testing but I have no idea how to do it
better and fully test it, usually I solve quests on a real survey)
|
Does SC fetch some data from the API via /map right after the first upload and before triggering the revert? In case of a db fail over, there's typically a very small replication delay, which could cause some object (versions) to not being part of the /map call, if you send the /map query too quickly after the upload. JOSM handles this by processing the diffResult, iD has a delay of a few seconds right after the upload and before loading new data. If the data is coming from Overpass API, the replication delay will be at least 1 minute, if not longer. |
@mmd-osm Are you saying that one cannot rely on that this GET call will return always the current version of the element? * a revert is the same mechanism |
CGImap can point to different databases for read/write and read-only operations. During normal operations, both point to the same primary database server karm in Amsterdam, in which case there's obviously no replication delay. It might happen during a fail over, that a read-only mirror katla is used for /map and other GET operations, i.e. you might experience a few seconds delay (see https://munin.openstreetmap.org/openstreetmap.org/katla.openstreetmap.org/postgres_replication_9_5_main.html). As you're already updating your local data from the diffresult, you're not immediately affected by a potential replication delay in a similar way as iD, which is using a /map call to reload all local data. Nevertheless, you could still cross check the object/object versions you received in the diffResult with what a subsequent GET call returns. If the diffResult announced a newer version compared to the GET call, there might be some replication delay/issue. Here's the respective iD issue: openstreetmap/iD#1646 with has some further pointers. Some of the discussion may not be relevant anymore, I don't recall exactly, how the replication was set up before the move to AMS. For the problem at hand, it would be good to see the actual error in the log files... just wanted to raise a bit of awareness, that replication delays could potentially happen. |
I can do this, though I wonder is it feasible to use test editing API to avoid nonsense edit-revert cycle in main database. It may be tricky, as I would need to somehow match what overpass server returns with content on https://master.apis.dev.openstreetmap.org - probably by populating master.apis.dev.openstreetmap.org with suitable data and running my private overpass loaded with selection of test api data. |
@mmd-osm Actually, I do not even update the element via a GET call. Knowing that the app was the last one who did a change on the element (otherwise there would have been a conflict), I simply take the (local) version of the element - the one I had been uploading - and give it the new version returned from the diffResult before saving it back to local storage. Is this assumption wrong? @matkoniecz Well to test generally new quests, the easiest way would be to
Using the test editing API is inconvenient because as you note yourself, there is no actual "normal" data on it. However, the matter at hand is more important right now - if this really is reproducable, this is a bug of potentially highest criticality. |
No, that looks ok. JOSM does it the same way. |
I finally started testing it a bit - one of things that would be nice is to log undoes, like quest solvings are logged (it may allow to distinguish "undo edit failed to edit OSM database" and "there was no undo edit at all") |
Doesn't it already? The log tag should be different. |
No sign in logs (I solved quest and undid it and solved again, without uploading).
|
I mean these logs here: https://github.com/westnordost/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/data/osm/upload/AOsmQuestChangesetsUpload.java#L133 The |
I think I understand the problem now. While the change is uploading, so after the |
During testing #1432 I made a test edit in a live OSM database that I immediately reverted[1]. To my surprise revert was not actually applied - see history of https://www.openstreetmap.org/way/22766359/history
For example https://www.openstreetmap.org/changeset/71430814 contains test edit adding access tag, revert edit was not applied. Selecting "undo" again was showing toast that nothing more can be undone.
It may be caused by competing edits and undos applied to the same some object in a short time, I am not considering likely that #1432 code is buggy.
[1] not the optimal way of testing but I have no idea how to do it better and fully test it, usually I solve quests on a real survey - in this case the nearest quest was quite far away from me
The text was updated successfully, but these errors were encountered: