Background Actualization of IDs only when App is started

gigiCom commented 4 years ago

Background Actualization of IDs only when App is started.zip

Avoid duplicates

[X] Bug is not mentioned in the FAQ
[X] Bug is not already reported in another issue

Describe the bug

The actualization of the risk, i.e. of the IDs that are present on the server, does only happen if the app is started and not if the app is closed.

This contradicts the published statement that the app does actualize in background.

This behavior means that persons who have installed the app, closed it and don't open it anymore, will never get informed about potential critical Corona contacts in the past, because the system does not download the risky IDs at all.

Only if the app gets started or if the app remains started (in the background), the IDs get downloaded. But not if the app is closed.

I have the background actualization switched on (see attachment), and I attached a video that shows (in slow motion) that I have actualized my IDs yesterday at 8:59. Today, I start the app at 10:40 and see immediately that the time stamp in the green risk panel switches from 8:59 to 10:40. I reproduced that behavior on my iOS phone 2 times in the last days and also 1 time on another iOS phone. On Android phones, this all seems not to occur.

If one lets the app open in background, this behavior does not occur, the IDs get updated in the background as expected, e.g. every day at 8:59.

Expected behaviour

The app should do the ID update in the background even if the app is closed, this is the expected and communicated behavior to the public, and it is the behavior on Android phones.

Steps to reproduce the issue

start the app and verify the latest actualization time stamp in the (green) risk panel, e.g. today, 8:59
close the app, don't send it in in the background, close it completely
wait until the next day after 8:59, e.g. 10:40
open the app -> one sees that the time stamp changes from yesterday, 8:59 to today, 10:40

see attached video.

If the app remains started (even in the background), and you bring it to the foreground the day after at 10:40, you see the time stamp shows today, 8:59.

Technical details

iOS Version: 13.5.1
Device: iPhone XS

Internal Tracking ID: EXPOSUREAPP-1832

tkowark commented 4 years ago

The problem is not a server load issue, but also related to the rate limiting for doing exposure checks through the ENF. This is also discussed in detail here: https://github.com/corona-warn-app/cwa-backlog/issues/2

Addition: if that rate limit is exceed, you get the infamous Error13

And the 10x entries your are seeing in your exposure logs are answered here: https://www.coronawarn.app/de/faq/#multiple_exposure_checks

BastianZim commented 4 years ago

The problem is not a server load issue, but also related to the rate limiting for doing exposure checks through the ENF. This is also discussed in detail here: corona-warn-app/cwa-backlog#2

Yes, that's what I was referring to but couldn't find anymore. Thanks for linking it! @tkowark

sin-azucar commented 4 years ago

I'm sure that has been considered, so I feel almost stupid asking: But have you thought about decoupling the background task's scheduling interval and the rate limit interval of the internal Apple API? For this to work, the app would record the timestamp when it last successfully submitted something to the API. Now, the job itself can be scheduled much more often than every 24 hours (e.g. every 2 hours, taking into account that in reality it will be more like 2-6 hours or even more...). On every invocation it would check whether the last API-call was >= 24h ago and return immediately if that's not the case.

This might also prevent some of the "Error 13" errors, because it's an additional safeguard against accessing the API more often than allowed.

i336616 commented 4 years ago

The problem is not a server load issue, but also related to the rate limiting for doing exposure checks through the ENF. This is also discussed in detail here: corona-warn-app/cwa-backlog#2

Yes, that's what I was referring to but couldn't find anymore. Thanks for linking it! @tkowark

Hey @mkuhn & @gigiCom, @Lucurus is 100% correct in relation to the 24hr limit, this is a restriction placed by Apple & Google on their framework usage. It's my understanding that they're looking into reducing this time-limitation in a future update, but unfortunately it's not within our control to manage this, so for the moment, we're stuck with the 24hr limit on API calls.

i336616 commented 4 years ago

I'm sure that has been considered, so I feel almost stupid asking: But have you thought about decoupling the background task's scheduling interval and the rate limit interval of the internal Apple API? For this to work, the app would record the timestamp when it last successfully submitted something to the API. Now, the job itself can be scheduled much more often than every 24 hours (e.g. every 2 hours, taking into account that in reality it will be more like 2-6 hours or even more...). On every invocation it would check whether the last API-call was >= 24h ago and return immediately if that's not the case.

This might also prevent some of the "Error 13" errors, because it's an additional safeguard against accessing the API more often than allowed.

@sin-azucar Not a stupid question at all, in fact that's exactly how we implement it in the app. The task scheduling occurs every 4 hrs, but we check the config every time just before we make the submission API call to determine if we can make the remote request, and returns straight away if it's still within the restricted period.

BastianZim commented 4 years ago

@i336616 Thanks for the confirmation, that makes sense as I've never had a bigger delay between calls than 24h + 4h.

mss1010 commented 4 years ago

The problem is that the developer decided very early against pushing updates through silent notifications. Running background tasks on iOS is very limited. Especially if the user doesn’t use the app regularly.

@i336616 Can you please comment on that? I´m not familar with how the background or other types of notifications work on iOS. But would this be an alternative to wake up the app more reliably? As we see, both on iOS and Android it´s currently not possible to reliably run the app in background mode, so can you explain why or why not notifications are an option to achieve that?

pkreissel commented 4 years ago

So I think the assessment that this is not a hard "doesn't work", but that it is more of a transient delay (due to iOS note necessarily running the bg tasks with high enough priority), is valid. This still means that for some devices, the update could be delayed for an undetermined time.

I saw on multiple phones now, that this is in fact a "hard doesn't work". On those phones there were no updates for days. I restarted my phone 2 days ago and didn't receive any updates since (haven't opened the app). I think this could be the cause.

mss1010 commented 4 years ago

So I think the assessment that this is not a hard "doesn't work", but that it is more of a transient delay (due to iOS note necessarily running the bg tasks with high enough priority), is valid. This still means that for some devices, the update could be delayed for an undetermined time.

I saw on multiple phones now, that this is in fact a "hard doesn't work". On those phones there were no updates for days. I restarted my phone 2 days ago and didn't receive any updates since (haven't opened the app). I think this could be the cause.

Yesterday the background update worked the first time for me. I changed the iOS settings for background update to „fully on“ and activated WiFi. Before that, I had the background update only on for WiFi and had WiFi deactivated.

Sounds a bit weird, I will monitor it further with different settings the next days to narrow it down.

PalminX commented 4 years ago

I saw on multiple phones now, that this is in fact a "hard doesn't work". On those phones there were no updates for days. I restarted my phone 2 days ago and didn't receive any updates since (haven't opened the app). I think this could be the cause.

Well, in order to schedule the background tasks, the app has to be started at least once after a phone reboot, as far as I understand.

pkreissel commented 4 years ago

I saw on multiple phones now, that this is in fact a "hard doesn't work". On those phones there were no updates for days. I restarted my phone 2 days ago and didn't receive any updates since (haven't opened the app). I think this could be the cause.

Well, in order to schedule the background tasks, the app has to be started at least once after a phone reboot, as far as I understand.

this is terrible. I know a lot of people who power down their phones at night.

i336616 commented 4 years ago

I saw on multiple phones now, that this is in fact a "hard doesn't work". On those phones there were no updates for days. I restarted my phone 2 days ago and didn't receive any updates since (haven't opened the app). I think this could be the cause.

Well, in order to schedule the background tasks, the app has to be started at least once after a phone reboot, as far as I understand.

this is terrible. I know a lot of people who power down their phones at night.

@pkreissel @PalminX As this is a limitation on the OS, not sure this is an issue we can resolve. I'll raise this with our Apple colleagues to see if they can suggest a solution.

mss1010 commented 4 years ago

I saw on multiple phones now, that this is in fact a "hard doesn't work". On those phones there were no updates for days. I restarted my phone 2 days ago and didn't receive any updates since (haven't opened the app). I think this could be the cause.

Well, in order to schedule the background tasks, the app has to be started at least once after a phone reboot, as far as I understand.

Oh really??? Oh my god! Then this probably explains the different behaviors of background updates working or not. I switch off my phone every night, and obviously I do NOT plan start the app every day manually. The last days I just did it in order to test things, but obviously that´s not the intended use of the app.

Ok, it´s a limitation of iOS, but that´s REALLY REALLY BAD. In the meanwhile I lost all my confidence in the benefit of this app. There are way too much stones in the way to make it a success. I will not mention the other fundamental issue here, but for this topic: Basically this means, that you need to start the app manually after each reboot. I´m quite sure, that nearly NO USER knows this.

Maybe this should be included in public information about the app.

Question to SAP and Telekom: Can you estimate from the server statistics, how many devices are getting the daily updates? Based on the number of active installations, you could anonymously analyze, how much installations are getting the daily updates, and how much don´t because of all this terrible mess here.

diveflo commented 4 years ago

I lost all my confidence in the benefit of this app. There are way too much stones in the way to make it a success. I will not mention the other fundamental issue here, but for this topic: Basically this means, that you need to start the app manually after each reboot. I´m quite sure, that nearly NO USER knows this.

I think you highly overestimate the percentage of people who even semi-regularly shutdown/reboot their phone.

mss1010 commented 4 years ago

I think you highly overestimate the percentage of people who even semi-regularly shutdown/reboot their phone.

Might be. Maybe I‘m not the average user 😉

Offtopic: However, the whole usage of the app way too low for several reasons. Currently, there are around 8000 confirmed active infections in germany, and just 300 of them used the app to get a code. This for sure does not consider demographics or familiy constellations, etc.

sin-azucar commented 4 years ago

I think you highly overestimate the percentage of people who even semi-regularly shutdown/reboot their phone.

While we can only speculate about that, I would say that almost everyone's phone gets turned off at some point. Maybe because you go to a place, where you more or less have to switch it off (movie theater, TV studio) or because you involuntarily run out of battery (happens to me all the time 😵). The bottom line is, even if this happens just once, the app will never again schedule a background task until the user decides to open it again.

I agree with @pkreissel and @mss1010: This is really a deal breaker. 😞

PalminX commented 4 years ago

I think the only way around this would be to schedule push notifications (in addition to the current background task scheduling). But I am also not an expert on iOS programming

pkreissel commented 4 years ago

While we can only speculate about that, I would say that almost everyone's phone gets turned off at some point. Maybe because you go to a place, where you more or less have to switch it off (movie theater, TV studio) or because you involuntarily run out of battery (happens to me all the time 😵). The bottom line is, even if this happens just once, the app will never again schedule a background task until the user decides to open it again.

I agree. I never power my phone down voluntarily, but its old and runs out of battery weekly. We are now at 18% usage in the German population. This is 3% higher than the 15% necessary for the app to have an effect according to Oxford Study. So if only 1 in 6 sometimes turn off their phones, then the App becomes useless for everyone else.

This should be the highest priority bug on here.

tkowark commented 4 years ago

Thank you all again for your input. As mentioned in one of the earlier comments, @i336616 is investigating the issue and also discussing with the colleagues at Apple how to best ensure that the background jobs are also triggered after a restart.

We understand both the issue itself and the urgency of it.

Since we currently also see now further technical input being required, we will lock the conversation and give an update as soon as we have finished our investigation and can provide a solution for it.

SebastianWolf-SAP commented 4 years ago

According to recent discussions (see e.g. #920) missing background updates also occur under iOS 13.5(.1) if the app was started once after restart. We clearly see that under iOS 13.6, but the bug might have already been there in iOS 13.5 (or was introduced in a recent CWA version).

ghost commented 4 years ago

Hello @gigiCom,

This issue has been fixed (Release 1.2) and will be closed now. If you have additional questions or comments, please feel free to reach out :-)

Thanks, LMM

Corona-Warn-App Open Source Team

corona-warn-app / cwa-app-ios