Streetcomplete: Quests are uploaded unexpected late in some situations

Created on 22 Sep 2018  Â·  18Comments  Â·  Source: westnordost/StreetComplete

I had answered the Opening hours quest for the supermarket

https://www.openstreetmap.org/node/356742928
with 4G internet. Walking into the building i had only EDGE (or less) and entered the hours for the backery

https://www.openstreetmap.org/node/356756677

But the second quest was not uploaded till now.
Osm Auth is set and auto upload is on. I have no +1 visible

Right now i can undo the hours for the backery, so i seems the app thinks the change was successfully uploaded...

bug

All 18 comments

Do you have Auto-Sync on?

OP said:

auto upload is on

I know it is hard to find and fix but still wanted to report... :-(

Basically, the app should be notified by the system as soon as a connection change occurs (but only while the app is in the foreground). This should trigger another attempt to upload the changes.

The main point imo is:
When is the quest marked as uploaded? When the request send (could have connection problems) or when the OSM API ack was parsed?

BTW did you use v8? If not, maybe it helps…

for auto-sync=on users, the star count is increased immediately, right when the quest is solved, before an attempt is made to upload the change. (Because the user is not supposed to have to care about that, the app is doing this automatically.)

The star count is uninteresting, the state of the osm object matters. And here osm and my sc are out of sync

What?

SC thinks osm got the Opening hours of the poi.
But osm has not the data.

I suspect current code:
Sc sends change to osm. If android reports (tcp) problems it will retry. In this rare case android lost the packet but did not noticed.

Proposed code:
Sc sends change to osm. If no Osm api ack (edit: diffResult xml) is received it will retry.

Disclaimer: i dont know osm api in detail and know nothing about sc sync code

You misunderstood.

If SC does not successfully upload a change, it will retry later either when

  • it is notified by the system that internet connection is available again
  • the user answers another question
  • maybe on some more occasions

SC will not ever forget a change made by the user that is not successfully uploaded yet.

On autosync=on mode, this happens all under the hood, the user will neither be informed about that an upload was not successful and it will try again later nor about that it was successful, as said, because the user needn't worry about it. SC will try again automatically.

Proposed code:
Sc sends change to osm. If no Osm api ack (edit: diffResult xml) is received it will retry.

So, this is already the case.

I just checked: the quest was uploaded 12h ago! 12 h after entering the data in which i often opened the app (but not answered a quest).
This took a while, but nothing was lost!

Sorry for the noise

I want to check when an automatic upload is triggered, perhaps the app can check this more often.

Or did you answer that last opening hours and then close the app?

It is quite possible that i added backery data and closed sc (which was on EDGE not fast enough to upload)

perhaps the app can check this more often.

i checked the area via Vespucci. this was the reason why i noticed the missing data.

I searched for new quests (a few hours later on wifi) as this is the only option i had. This should upload ,too.

What did not triggered imho

  • app reopen
  • manual search
  • app reopen with wifi available

Auto upload is currently triggered when:

  • app regains connectivity after it lost connectivity before
  • when you solve a quest
  • when you leave a note instead of solving a quest
  • when you undo

I will add

  • when the app comes back into foreground
  • when you create a note

Could be ok (mainly because of the forground trigger).

But you decided against "manual search". In the user view this is the only GUI "sync stuff" trigger i have.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

HolgerJeromin picture HolgerJeromin  Â·  3Comments

RubenKelevra picture RubenKelevra  Â·  3Comments

matkoniecz picture matkoniecz  Â·  3Comments

lzmartinico picture lzmartinico  Â·  4Comments

RubenKelevra picture RubenKelevra  Â·  4Comments