[iOS 13.6] After updating to iOS 13.6, consistently only 13 instead 14 sets of data per day appear in the encounter check log

[gkgg]

This is a question regarding the expected behaviour of the framework and/or environment.

I observe that after applying the iOS 13.6 update three days ago, the log showing the downloaded/processed data includes 13 sets. While on iOS 13.5.1, this number of sets went up to 14. (There had been an issue with those sets downloaded/processed with app version < 1.0.7.)

The question is if this behaviour (only 13 sets of data showing up in the log) is expected with iOS 13.6.

Thanks in advance!

[Ein-Tim]

I observe the same behaviour on my iPhone XR with iOS 13.6
Running CWA version 1.0.7

[HeiDasGri]

On my phones I do not see this behaviour. Maybe it depends on the exact time.
iPhone 8 iOS 13.6:

• 19.07. 07:09 (14 Files)
• 17.07. 18:12 (14 Files)

iPhone 11 iOS13.6:

• 19.07. 10:37 (14 Files)

[son1c]

I have the same behavior on an iPhone XR (13.6) and iPhone 11 (13.6) only 13 Files instead of 14.
Both iPhones run version 1.0.7 of the app

[Skibbe69]

I see the same behavior but I am still on iOS 13.5.1:

• iPhone 11 PRO
• iOS 13.5.1
• CWA Version 1.0.7 (0)
• 19.07. 13 Files
• 18.07. 13 Files
• 17.07. 14 Files
• 16.07. 14 Files

[Tho-Mat]

It depends on the hour you download the files.
Normally old files are deleted 14day after they have published.
So it could and does occur, that at some time there are only 13 days to download.
Assume the last keys of a day have been publish at 17:00 14 days ago.
If you download the set in the time from 17:06 to 02:04 you will get only 13 sets.
If you download the set before 17:05 or after 2:06 you will get 14 sets.

[haosap]

Hi @gkgg,
Thanks for your report. You mentioned after upgrading iOS 13.6, it happened. How does it look like for iOS 13.5? Did it even happen?

[gkgg]

Hi @haosap,
sadly I have no device at hand running iOS 13.5 or 13.5.1. But it looks like @Skibbe69 was able to observe said behaviour on iOS 13.5.1, see comment above.

That said, it might as well be more of a correlation than a causation that this started happening the day I installed iOS 13.6. (Changing the title of this issue might be a good idea.) Starting 07/16/20 at 19:06, that is what I see in my phone's log.

If there is anything I can do on my side, please let me know.

[Skibbe69]

Hi @haosap if you need further details from my side just let me know. I am still on iOS 13.5.1 and waiting for today's downloads.

[haosap]

Hi @gkgg , Hi @Skibbe69 ,
Thank you so much for your support. The bug is very hard to be debugged and reproduced, as it works in my device. Internally we have started to do the investigation on it. We'll contact you once we need further information.
Thanks.

[Tho-Mat]

@haosap
As i mentioned above. It’s not a bug in the ios app. It only belongs to the cwa-server

[gkgg]

Just to add some maybe useful information, here is the list of the dates, times and number of sets I can see in the log:

• 07/14/20 18:03 14
• 07/15/20 18:37 14
• 07/16/20 19:06 13
• 07/17/20 19:34 13
• 07/18/20 20:40 13
• 07/19/20 20:47 13
• 07/20/20 22:39 13

I downloaded and installed the most recent version (v1.1.1 (3)) of the app just this morning. Due to the ongoing and delay of the background task for downloading (and processing) I won't be able to provide any updates until tomorrow morning.

[Skibbe69]

Also here my download history including the time:

• 200713 10:42h 5 files
• 200714 10:45h 14 files
• 200715 12:01h 14 files
• 200716 13:02h 14 files
• 200717 13:36h 14 files
• 200718 20:04h 13 files
• 200719 21:27h 13 files
• 200720 21:35h 13 files

I see also the 13 files are downloaded always after 20:00h. Maybe there is a correlation and @Tho-Mat theory is worth
to be investigated further.

Status of app and hardware:

• iPhone 11 PRO
• iOS 13.5.1
• CWA Version 1.0.7 (0)

[haosap]

@haosap
As i mentioned above. It’s not a bug in the ios app. It only belongs to the cwa-server

Hi @Tho-Mat ,
Thanks for your info. It seems the report from @gkgg and @Skibbe69 follows the pattern.
Hi @ChristopherSchmitz , @mlenkeit
Could you please align with backend colleagues? Thanks.

[haosap]

Hi @pwoessner ,
Could you please check if the behaviour is the same for Android client?
Thanks.

[sin-azucar]

@Tho-Mat is right, I curled the endpoint yesterday (forgot to take note of the exact time 😞) and today again.
Yesterday sometime in the afternoon:
curl https://svc90.main.px.t-online.de/version/v1/diagnosis-keys/country/DE/date
["2020-07-07","2020-07-08","2020-07-09","2020-07-10","2020-07-11","2020-07-12","20 20-07-13","2020-07-14","2020-07-15","2020-07-16","2020-07-17","2020-07-18","2020-07-19"]

Today just now:
curl https://svc90.main.px.t-online.de/version/v1/diagnosis-keys/country/DE/date
["2020-07-07","2020-07-08","2020-07-09","2020-07-10","2020-07-11","2020-07-12","20 20-07-13","2020-07-14","2020-07-15","2020-07-16","2020-07-17","2020-07-18","2020-07-19","2020-07-20"]

So it's not a bug in the app, it just depends on what the server has to offer at different query times.

[Skibbe69]

Update on this from my side I have updated iOS to 13.6. & the CWA to 1.1.1
And the downloads look now as follows:
- 200721 22:16h 13 files
- 200722 no download
- 200723 0:56h 13 files

'Hintergrundaktualisierung' is activated for the CWA

[gkgg]

Update on this issue from my side.

• 07/20/20 22:39 13
• 07/21/20 no background update took place during the night :-(
• 07/22/20 04:13 14
• 07/23/20 04:15 14

So today and yesterday in the morning, the expected number of sets have been downloaded … on starting the app/activating the app, I should add.

That for whatever reason the background task of downloading/processing the files automatically "somewhat 24ish" hours after the last update had taken place behaves strange (in case it appears anyway) well, that is a different story already discussed in a different open(?) issue, if I am not mistaken.

[christian-kirschnick]

Hey *,

this is actually a duplicate of corona-warn-app/cwa-server#650. The problem was, that already published files were retroactively modified due to retention enforcement & shifting policy enforcement. This always affected the "oldest" file on the CDN, which was subject for deletion anyways the next day at 00:05 UTC. This means, that when you mobile tried to download the 14 files for the last 14 days, the 14 day old file was already removed from the CDN.

Why this is not a problem: Keys relevant for risk calculation were always provided by the backend & checked in the app. Only keys, which distribution date is older than 14 * 24 hours have been deleted - those keys are not relevant for matching, as they are too old.

Example: Let's assume 14 days ago, somebody uploaded his keys at 10:00 UTC. Today, at 11:00, his keys would be deleted, as the retention threshold is reached. This unfortunately lead to an update of the daily file. If this now was the only upload for the day, then the day file would also be not listed anymore in the index file - so the app would be unable to discover the file. Again: No functional impact, as only the too-old keys were deleted, which are not relevant anymore anyways. Therefore you guys discovered this issue mainly when the download from the CDN was triggered late in the evening, and not in the morning. The later you downloaded the files, the higher the chances the "older" keys were already deleted.

This was fixed and the fix will be shipped with the 1.2 release. From there on, the bug which changed the files retroactively on the CDN is fixed, so the files will stay immutable - as it was originally planned.

Sorry for the confusion, and thanks for all the hints.

cheers
Christian

[tkowark]

Thanks for the explanation, @christian-kirschnick . Since the issue is a) on the server side and b) will be resolved in future versions, we'll also close this issue here in the iOS repository.

[Bernhard387]

Hey,
I am not a developper but I was told at the hotline that this is an issue that might by of interest to you. It concerns the entry "Ausgetauschte Schlüssel" which in my case is "0" for all entries and the app reporting 2 "Risikobegegnungen" of high risk.

It is an iphone SE 1st generation and IOS 14.0.1. I checked all entries and it says "0" for all entries. To my understanding the app would have no reason to report positive contacts as this is not what is found in "Begegnungsüberprüfungen".

Regards
Bernhard

[daimpi]

Hi @Bernhard387,

the issue you're experiencing is tracked over here. The number of "Abgeglichene Schlüssel" displayed in the log is wrong but it looks like this bug will be fixed with iOS 14.2.