House number quest is asked again immediately after solving it #5545
Comments
|
Uff. Oh no. Can you add the logs for time when this happened? |
|
2024-03-21T16 0.txt |
|
Summary:
Observations:
Takeaways for now:
|
|
blocked until new release |
|
Had another case with a kerb height quest today https://www.openstreetmap.org/node/9480862703/history (happened while updating quests). Do you wan the log? |
|
No. Next version will have some more logging, so maybe that will give a hint where this issue comes from. |
This comment was marked as resolved.
This comment was marked as resolved.
|
Since v57.2 we have some additional logging in place. This might help finding the issue. So when this bug appears again, I'd appreciate if you posted the log here. |
westnordost
added
the
feedback required
|
Can be reopened when it happens again. In that case, we need the log, as I added additional logging over six month ago. |
|
Well, I think it probably still happens. My case is from SCEE 58.2 with extra SCEE quest, but it should have #5473 alleged fix (e2621c7 mentioned there should be present from (Un)fortunately it happens rather rarely (I notice it maybe once in a few months), so I don't have example from pure SC (as I mostly use SCEE nowadays)... It just so happens I had one of those today; here is example changeset 159639189 in which node 12377419129 has multiple answers for same quest While I have problems easily sharing logs (due to #5561 and me having some ~3500+ loglines today), I've manually limited the results in several time ranges and concatenated them, so hopefully I've managed to extract all related logs. Here are the those logs (as mentioned, SCEE 58.2, but hopefully it still helps) that probably relate to the issue: I'm suspecting it happened between timestamps |
|
Do you have auto-sync on or did all that happen offline (i.e. can't be a result of something going wrong during upload)? Cause, I don't see node 12377419129 mentioned in the log. |
No, I have
So I would expect that node to be one with "anonymous" negative numbers, as it didn't get official number 12377419129 until dozen hours later when I got home and uploaded all few hundred quests via WiFi. |
|
The relevant node in the logs is Logs |
|
I'll go through this log in the next few days, but note that SCEE has some code changes that might introduce this bug. So maybe this doesn't concern SC. |
|
What I read from the log (in order):
Looke very much like the download completes and persists quests before the single edit, but is overtaken by the single edit somewhere on the way to SCEE is more susceptible to this issue, but as far as I understand it can occur in both SCEE and SC. |
|
hmm, does that explain why it also persists? I.e. the quest wont go away even after solving it multiple times.
El 27 de diciembre de 2024 8:34:59 CET, Helium314 ***@***.***> escribió:
…What I read from the log (in order):
1. quests from a download are created while the quest form is open
2. the quest is solved
3. the quests from download are persisted in DB
4. new quests for bench are created
5. visible quests source gets a new quest for bench, and one to delete (in SCEE this can happen before 6., in SC it cannot)
6. bench quests are persisted in DB (including the deletion)
7. visible quests source gets new quests from downloaded area (which I assume includes the bench quest)
Looke very much like the download completes and persists quests before the single edit, but is overtaken by the single edit somewhere on the way to `VisibleQuestsSource.updateVisibleQuests`. This can happen in `OsmQuestController.onUpdated` (filtering quests hidden by notes), and in `VisibleQuestsSource.osmQuestSourceListener.onUpdated` (filtering invisible quests).
It's not explicitly in the log, but I'm fairly certain that the download (`mapDataSourceListener.onReplacedForBBox`) called `OsmQuestController.onUpdated` just a few ms before the single edit (`mapDataSourceListener.onUpdated`).
SCEE is more susceptible to this issue, but as far as I understand it can occur in both SCEE and SC.
--
Reply to this email directly or view it on GitHub:
#5545 (comment)
You are receiving this because you modified the open/close state.
Message ID: ***@***.***>
|
I think so. The quest is not in the database, so it's not in |
|
Thanks a lot for the investigation @Helium314 !
So, if I'm getting this correctly, if one were to add artificial delays (e.g. |
|
I added a test that reproduces what I think is happening.
|
|
Without proper investigation: maybe the solution could be similar to |
|
Thank you for this test case! Unfortunately, after having a long look at it, I didn't follow, the test case doesn't help me understand the cause. I would like to avoid a solution like TBH I still don't quite understand the flow after an hour or so of looking at it and where exactly the race condition is located. I mean, there are synchronized sections in the |
Yes, that could definitely solve the issue. The drawback would be less responsive UI when solving quests while quests are created / persisted (bottom sheet is closed only after quest edit is persisted, and if that needs to wait for
Calls to
I'll try.
Key points:
|
|
Thank you, will look at it again more closely tomorrow! Hopefully I can then come out with a proper and more concrete suggestion or solution. Could you update the table to show exactly the order of things where it matters? E.g.
After all, nothing really happens in parallel, and that one task "reingrätschen" into another while that one is still executing is the prime reason for any race condition. It would be most graphic to see clearly depicted in that table, where that happens. |
In my understanding there are 2 sections where a small (single element) |
|
Now I understand, yes, now I can follow! I agree that there are two points where one thread could overtake the other, the first being much more likely than the second. |
westnordost
removed
the
feedback required
|
While looking at the code, it's somewhat odd that OsmQuestSource does not include all the OSM quests, but only those that are not hidden by the user. I.e. OsmQuestController also manages OsmQuestsHiddenDao. It seems to me on first glance that it would make more sense to have another QuestsHiddenController that would manage both OsmQuestsHiddenDao and OsmNoteQuestsHiddenDao rather than to have the logic whether a quest is hidden or not be scattered between two classes (OsmQuestController and VisibleQuestsSource). On the other hand, OsmQuestsHidden* classes kind of belong to the osmquests package from the data point of view. 🤔 |
I hope what I saw today is not another case of #4258, but I was asked to solve a house number quest several times again after solving it during a quest update download. See screen shot (note it's asking for the house number of the apartment building with house number 4, i.e. the number is already known). Restarting the app made the quest go away. Maybe #5473 was not a complete solution?
Edit: I noticed in the history of the object here https://www.openstreetmap.org/way/1135323961/history that each time I answered the house number quest again, a new edit was made to the object. The house number quest was preceded with an "Is this building still under construction?" quest, which I answered with Yes. That answer apparently resulted in the activation of the house number quest, but not in an edit to the object (it's still under construction on the map).
Versions affected
Android 10, StreetComplete 57.1
The text was updated successfully, but these errors were encountered: