Cwa-app-android: [upcoming bug] exceeded quota when using with future versions of GMS

[kbobrowski]

Avoid duplicates

• [x] Bug is not mentioned in the FAQ
• [x] Bug is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in the documentation repository
• [x] Bug is not already reported in another issue

Describe the bug

I've reached out to Google to make documentation more precise as to when quota on provideDiagnosisKeys is set to zero (related to a bug described in https://github.com/corona-warn-app/cwa-app-android/issues/822), and was expecting description to simply state that quota is nullified at midnight UTC as it is done currently, but it was updated to:

Days are 24-hour windows that begin at the time the method is first called.

It looks like this change will be simply triggered by GMS update, regardless of whether original or v1.5 API is used, which would result in exceeded quota in the following scenario:

• user updates Diagnosis Keys at 15:00 UTC
• user opens CWA at 02:00 UTC and update of Diagnosis Keys is triggered again
• quota is exceeded, as it was already at 14 at 15:00 UTC, and will go past 20 at 02:00 UTC update (quota is nullified only at 15:00 UTC next day)

Possible Fix

One option is to track when Diagnosis Keys were last updated, and allow update only after 24 hours from the time this method was first called. But it would revert some progress in the efforts of reducing exposure notification delay as discussed in https://github.com/corona-warn-app/cwa-backlog/issues/2 . Following scenario would be possible:

• user updated Diagnosis Keys at 23:00
• next update is only possible next day at 23:00, despite fresh Diagnosis Keys being available already since 23 hours
• total delay in exposure notification (including delay due to consuming only daily bundles of Diagnosis Keys) is up to 48 hours, and cannot be reduced by the user in any way (currently it can be reduced to around 24 hours by opening CWA early in the morning)

Proper solution here is probably to quickly migrate to v1.5, then it would be possible to update Diagnosis Keys every 4 hours and the timing of when exactly quota is nullified would be introducing 4 hours additional delay in the worst case (even less if hourly bundles would be consumed), not 24 hours.

---

Internal Tracking ID: EXPOSUREAPP-1910

[SebastianWolf-SAP]

Thanks for that hint. We will discuss that with our dev colleagues. Maybe we will eventually need to merge this issue with https://github.com/corona-warn-app/cwa-backlog/issues/2 and https://github.com/corona-warn-app/cwa-documentation/issues/373 - just keep track of all information related to API version upgrades, underlying behavioral changes and required changes on our side. For now, we keep it open until we have further information.

Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

[w-flo]

This should be really high priority unless SAP/RKI can get confirmation from Google that the change won't go live until this issue is taken care of.

As I understand it, in the current corona-warn-app, key updates will happen with less than 24 hours delay between them very often. So if this GMS update is planned to go live in a few days, users will probably see error messages and failing key syncs at least every few days with no way to fix them. They might install/uninstall a few times, which will not help, and then give up.

[kbobrowski]

Google changed it again to:

Days are defined as midnight to midnight of a device's local time zone.

So it seems the way of defining "day" is still being established. This change would also break CWA on all Android devices, as currently "day" is midnight to midnight UTC in both GMS and CWA, so agree with @w-flo that this issue should be high priority right now.

My feeling is that at this point it is necessary to make CWA robust w.r.t. how Google defines "day", as it may be difficult / impossible to synchronize CWA update with GMS update, unless there is a way to determine programmatically what is the definition of "day".

Possible way to get rid of any issues related to definition of "day" is to implement mechanism of retrying provideDiagnosisKeys let's say every 1 hour after it failed with 39508 (or maybe even any other error), and only after if has been failing consistently for 24 hours raise exception to the user, so it can be reported. This is not very elegant but has good potential of averting this and future unexpected issues with provideDiagnosisKeys (this mechanism would have made previous issues with error 10 / 39508 less severe).

Another option (assuming that Google will settle on resetting quota at midnight local time) is to make sure that the app can only update Diagnosis Keys if the date has changed in both UTC and local time zone - as an interim implementation to support both mechanisms

[tkowark]

Personally, I think that ignoring 39508 until it worked again or 24h passed would mitigate a couple of issues, e.g., when the error is triggered after switching from swiss covid (#816). But we'll discuss this with the dev team early next week to find a proper way forward. Thanks again for all your input on that matter!

[kbobrowski]

Google fixed docs - count resets at midnight UTC