Resetting the CWA triggers error 39508

[pathmapper]

Avoid duplicates

• Bug is not mentioned in the FAQ
  The error itself is mentioned, but it's unfortunate that using a regular functionality of the CWA ("Anwendung zurücksetzen") triggers the error.
• Bug is specific for Android
• Bug is not already reported in another issue
  It was reported in Fehler bei Kommunikation mit Google API (39508) #774 (comment) but this issue is closed now and I was asked to open a new issue (Fehler bei Kommunikation mit Google API (39508) #774 (comment))

Describe the bug

The error 39508 appears if the CWA is resetted (Settings menu -> "Anwendung zurücksetzen") and used again afterwards.

Expected behaviour

No error message because it could confuse the user ("Etwas ist schiefgelaufen").

Steps to reproduce the issue

Reset the CWA (Settings menu -> "Anwendung zurücksetzen") and use it again afterwards.

Technical details

Model: Motorola Moto G 3
OS: Android: 6.0.1 (not rootet)
CWA: 1.1.1
ENF: 15202902003

Possible Workaround

Wait until the next day, but it's unfortunate that using a regular functionality of the CWA ("Anwendung zurücksetzen") triggers 39508 for the rest of the day.

Additional context

#774

---

Internal Tracking ID: EXPOSUREAPP-1854

[pwoessner]

Hi @pathmapper
there is currently no fix possible for this issue. The reason for this is:
We can only download and update the Diagnosis Keys from the serve once per day (due to the quota limit of the Google ENF). We store timestamps in the application to check if we can already download and check for exposures or if we did that already on this day. As soon as you reset the app, we delete all the data (including the timestamp when we checked for exposures the last time). This will then cause the app to think that it can check today again for exposures but the Google ENF will throw the quota limit error.

Because we cannot do anything against this error I will close this issue.

Thanks,
Philipp

[vaubaehn]

@pwoessner
I'm sorry, I disagree that nothing can't be done about that issue.
If you catch the exception 39508 with proper error handling in a 'fresh install' of CWA (or with erased CWA-data), a message to the user might be thrown, that because of limits in Google's ENF the next update can only be done the next day. Then a flag might be set, that avoids throwing that message again for the current day. This at least gives proper information to the user and decreases anger related to CWA...

@pathmapper
One workaround is to also erase all data (not only cache) of Google Play Services, as this also seems to reset the counter for API 39508. But then also all collected keys to check for risk encounters are lost, and you also probably need to set up some other Play Services related things again (e.g., device backup account, credit card for GPay, and probaly others), so I would recommend this only as last resort, if nothing else (like waiting one day) helps.

[vaubaehn]

@tkowark see my comment above. May I kindly ask to keep this under observation as EXPOSUREAPP-1854 in jira? Thank you :)

[pathmapper]

@vaubaehn thanks for the workaround, I could wait for the next day. I opened this issue because it's confusing for users which didn't read a bunch of GitHub issues nor the FAQ.

@pwoessner it's understood that the error is because of limits in Google's ENF.
This issue is about how to handle this error, sorry if I was not clear enough with the issue description.

So I second what @vaubaehn outlined above:

If you catch the exception 39508 with proper error handling in a 'fresh install' of CWA (or with erased CWA-data), a message to the user might be thrown, that because of limits in Google's ENF the next update can only be done the next day. Then a flag might be set, that avoids throwing that message again for the current day. This at least gives proper information to the user and decreases anger related to CWA...

I think this is also what @tkowark wrote in #816 (comment):

39508 should ideally never be exposed to the user, but gracefully captured and a retry should happen at the next possible point in time

So please re-open this issue to track the error handling in this case.

[vaubaehn]

@pwoessner thank you :)

[2q2q]

@tkowark @pwoessner I encountered error 3598 among multiple non-technical users who are left without a clue and are re- or uninstalling the app completely. Please catch this exception and give users some meaningful instructions on how to workaround this. I dont think closing tickets like #934 is the appropriate decision.

[tkowark]

@2q2q this issue (or did you mean to reference another one?) ist still open and we'll discuss with the product management how to make this message clearer for the users to avoid the situations you mentioned.

[vaubaehn]

@2q2q this issue (or did you mean to reference another one?) ist still open and we'll discuss with the product management how to make this message clearer for the users to avoid the situations you mentioned.

@tkowark At least the message is now different ;) #864

[MikeMcC399]

Hi @pwoessner

there is currently no fix possible for this issue. The reason for this is:
We can only download and update the Diagnosis Keys from the serve once per day (due to the quota limit of the Google ENF). We store timestamps in the application to check if we can already download and check for exposures or if we did that already on this day. As soon as you reset the app, we delete all the data (including the timestamp when we checked for exposures the last time). This will then cause the app to think that it can check today again for exposures but the Google ENF will throw the quota limit error.

It seems that CWA > Settings > Reset App does not clear all the data in the app. I am seeing the following with
Corona-Warn 1.1.1 after executing Reset App

Type	Size
App	39.19 MB
Data	2.16 MB
Cache	799 kB
Total	42.15 MB

as shown by Android > Settings > Apps > Corona-Warn > Storage.

So after just using Reset App and running through the onboarding sequence CWA reports:
CAUSE: 3
Something went wrong.
Error when communicating with Google API(39508)

If instead, the app data is forcibly deleted through:
Android Settings > Apps > Corona-Warn > FORCE STOP
Storage > CLEAR DATA
then the onboarding runs through without any error message.

Android Settings > Google > COVID-19 Exposure Notifications
confirms with "Last checked for potential exposure today at nn:nn"
with a timestamp in-line with the previous error-free onboarding.

Does Reset App need to be looked at to make it delete all app data, so that CWA can run again immediately afterwards without error?

[vaubaehn]

Hi @MikeMcC399 , referencing from here -> #642 (comment), did you experience any difference in the deletion of the Exposure Notification checking history, whether CWA was FORCE STOPPED before clearing CWA data or not force stopped? Or is the history cleared anyway?

I'm asking, because it could indicate, which process is repsonsible to clear the history. If CWA was force stopped, data deleted and history cleared (before restarting CWA!), then ENF seems to actively monitor the data of any exposure tracing app. If the history is not deleted in that case of force stopped CWA, then CWA running in background seems to be responsible to trigger ENF to erase that history (e. g., by generating a new API key to call ProvideDiagnosisKeys). If the latter was the case, it would re-frame your question

Does Reset App need to be looked at to make it delete all app data, so that CWA can run again immediately afterwards without error?

and it is becoming even more likely, that RPIs/TEKs are also erased (like a complete uninstall/re-install).

[MikeMcC399]

@vaubaehn
We have to rely on the CWA Open Source Team to tell us what is going on with the data and there are limits to what is discoverable through black box experiments on test devices. The Google code is not published and so we can't read the code there.

It would make sense if the Google API could be extended so that it shows what data is available. Instead of CWA trying to remember and calculate how many days from 14 have been logged, the Google Exposure Notification system could remember and report this. At the moment the information presented to the user can be inconsistent as shown by #1117 (comment) from @thomasaugsten where he says that after resetting the app the data is still there, but the CWA will reset the day counter.

[svengabr]

@MikeMcC399 i made a comment to the main 39508 discussion here: #1021 (comment)

I am happy to announce that the error 39508 is well known by the development team and a fix is going to be rolled out within the next days with the hotfix release 1.3.1.

If you want to contribute to the existing discussion, please use the main issue here.

• CAUSE: 3 Something went wrong. ApiException: 39508 #1021
• Resetting the CWA triggers error 39508 #934
• Risikostatus wird nicht aktualisiert #1119
• Fehler bei Kommunikation mit Google API (39508) #774
• Auf Samsung Handy seit 2 Wochen Fehlermeldung 39508 #1130
• Google APIException (39508) after using the SwissCovid App #816

[MikeMcC399]

This issue (Resetting the CWA triggers error 39508) has been made much better after updating from CWA 1.3.1 to CWA 1.5.0.
(The fix did not make it into the 1.3.1 release despite the comment above #934 (comment) from @svengabr.)

On the device I used for testing there were 14 exposure checks logged at 02:06 today when CWA 1.3.1 was still running. After updating to CWA 1.5.0 then executing CWA > Settings > Reset App at 17:52 (also today) no error occurred.

As expected, after resetting the app a total of 6 times, the 7th attempt caused a 39508 error. 14 + 7 = 21 which is more than the quota of 20.

After 02:00 tomorrow, when the quota is reset and there is no history of a set of 14 exposure records for one day, then each re-initialisation of the app should cause only one exposure check record to be stored. So it means the app would need to be reset 19 or 20 times before the quota is exceeded and a 39508 error happens solely because of resetting the app.

This issue could be closed because the scenario of resetting the app 20 times is a very abnormal use. It might be worth mentioning it though as an (unusual) cause of 39508 in the FAQ entry https://www.coronawarn.app/en/faq/#API39508.

[svengabr]

Thank you for your detailed testing @MikeMcC399

I will close this ticket, for now, to keep the board clean.