Cwa-app-android: Bug with time zones, causing exceeded quota (39508 error)

[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
• [ ] Bug is not already reported in another issue

Describe the bug

Exposure Notifications framework is resetting quota at midnight UTC, not at midnight in current time zone. This may be causing 39508.

Current design allows for initiating RetrieveDiagnosisKeysTransaction at 15:00 CEST and then next day again at 01:00 CEST. This will result in exceeded quota, as it corresponds to 13:00 UTC and 23:00 UTC on the same day.

Already reported in https://github.com/corona-warn-app/cwa-app-android/issues/774#issuecomment-653819198 https://github.com/corona-warn-app/cwa-app-android/issues/774#issuecomment-653821030 https://github.com/corona-warn-app/cwa-app-android/issues/774#issuecomment-653821218 but separating the issue here since #774 is about error 10 which is causing 39508.

[eayin2]

I use UTC+7 instead of UTC+2 on Android 10 and I got following error message since today (I use this app over two weeks):

URSACHE 3:
Etwas ist schief gelaufen.
Fehler bei Kommunikation mit Google API(39508)

Removing the cache of Google Play Services didn't solve this error.

[fredsleeve]

Can you post your Exposition Notification log for the last checks? At 0700 in your TZ the error should be gone.

[jkrwdf]

I am in the UTC+2 (CEST) timezone and encounter this issue today for the first time (Pixel 3 XL, Android 10, GMS 20.21.17).

My pattern matches the bug description.

My personal action log as far as I remember:

• Opened CWA on 3.7. in the morning successfully
• Opened CWA on 4.7. in the morning successfully
• Opened CWA on 5.7. in the morning successfully
• Opened CWA on 6.7. at 00:01 with error message, reproducible multiple times
• Opened CWA on 6.7. at 03:05 successfully

Verification Log in GMS UI (timestamps are shown obviously in CEST, number in brackets is the number of individual rows with the same timestamp):

3.7.: 06:53 (10)
4.7.: 08:38 (11)
5.7.: 08:11 (4), 08:13: (8)
6.7.: 00:01 (8), 03:05: (13)

Interpretation:

From 3.7. to 5.7. all went fine, although the verification run on 5.7. was already split into to two timestamps two minutes apart.

When I opened CWA on 6.7. shortly after midnight it decided to perform the next run, and failed after 8 method invocations because on the same UTC-day, already 12 were done. The "Last updated" visual time in the CWA UI remained at "08:13".

In the new UTC-day (03:05 CEST = 01:05 UTC), the verification run could be executed successfully (13 keys).

[fredsleeve]

I can confirm these findings. As soon as 02:00 CEST (00:00 UTC) passed, the error is gone.

DATE  CEST  UTC     CHECKS   RESULT
3.7.  15:27 [13:27] (10)     ok
4.7.  02:00 [00:00]          EN resets
4.7.  15:15 [13:15] (11)     ok
5.7.  00:24 [22:24] (9)      error (quota 20 reached)
5.7.  02:00 [00:00]          EN resets
5.7.  10:35 [08:35] (12)
5.7:  10:38 [08:38]          ok, no error when CWA opened
6.7.  00:01 [22:01] (8)      error (quota 20 reached)
6.7.  01:59 [23:59] (12)     
6.7.  02:00 [00:00]          EN resets
6.7.  02:01 [00:01]          ok, no error when CWA opened

[MikeJayDee]

Just wanted to confirm that as expected this bug is still present in the current release version 1.0.5 (update of today). 15 checks were made at 7:00 in the morning, and then, after opening the app a few seconds after midnight, just 5 checks at 00:00.

[doak]

@MikeJayDee, looking at the history it looks like it will be available for the next (patch) release (e.g. 1.0.6).

[MikeJayDee]

I can confirm that this issue is resolved with today's update (version 1.1.1). Opening the app between midnight and 2 a.m. CEST did not result in an error message like it always did previously.