"Limit already reached" FAQ does not cover time travel issue

[MikeMcC399]

Where to find the issue

• https://www.coronawarn.app/en/faq/results/#limit_reached "[Google/Android]: Error after resetting the app: Limit already reached"
• https://www.coronawarn.app/de/faq/results/#limit_reached "[Google/Android]: Fehlermeldung nach Zurücksetzen der App: Limit bereits erreicht"

Describe the issue

The above FAQ article quotes the Android app's error message:

'Limit already reached'

'No more exposure checks possible today, as you have reached the maximum number of checks per day defined by your operating system. Please check your risk status again tomorrow.'

and repeats that the error should clear itself the next day.

This is not true if the mobile device's clock has been set to the future and then reset to the correct day. In this case the error message 'Limit already reached' continues to appear until the current day has advanced to the previously set future day.

• See also https://github.com/corona-warn-app/cwa-app-android/issues/5183 for screenshots of the different error messages.
  1. "Exposure check failed" with "Updated: Today"
  2. "Exposure check failed" with "Updated: some future date"
  3. "Limit already reached" with "Updated: some future date"

Suggested change

1. Add one or two FAQ articles covering the error messages which can be seen after a mobile device has had a future date set and this date is then corrected.

2. Remove the text "If the error message is still present the next day, you can report this via a comment in GitHub Issue 1459." from the #limit_reached FAQ article. Since the mentioned GitHub Issue 1459 is now quite old (it was closed more than one year ago), it would be better for users to open a new issue, if they face the same problem after resetting the app. If the problem comes from a future date, then in any case this is a different issue.

[MikeMcC399]

Before trying to write any additional FAQ material it needs feedback from CWA Android developers about what is happening. Can this issue be prevented? What are the recommended recovery steps?

[MikeMcC399]

There are three ways to recover from the "Limit already reached" error condition caused by time travel:

1. Uninstall then re-install the app
2. Reset the app
3. Reset the device's clock to the correct date and then wait until the clock advances to the day after the future date which was set by time travel

Re-installing the app seems to be the safest recovery method. I think there is a danger of incorrect risk calculations taking place if random IDs with incorrect date-/time-stamps caused by time travel are left behind. A combination of resetting the app and deleting Random IDs through the Google UI may avoid incorrect risk calculations, however since this method does not delete the history of exposure checks in the Google UI it leaves the UI data in a confusing state.

[MikeMcC399]

The questions are:

1. Should there be a new FAQ article written to cover "Limit already reached" after time travel?
2. If yes, should the article recommend uninstalling and re-installing the app?

[MikeMcC399]

• This issue affects newer versions of Android and it is planned to be fixed with PR https://github.com/corona-warn-app/cwa-app-android/pull/5465.
• The need to describe the issue in the FAQs still exists.

[GisoSchroederSAP]

Thanks for pointing out, @MikeMcC399. Over summer period we lost track a bit for single issues, so this reminder is much appreciated. Meanwhile, we had a conversation with our teams observing the app stores, mailbox and hotline. According to their observation the time travel topic doesn't seem to fit the frequently part in FAQ. In fact, we rarely get this question at all.

To avoid posting an increasing number of FAQ articles that are hardly ever used, we aligned: In a specific user inquiry we will answer directly that date/time shall be corrected on the smartphone. In case, this won't work or solve the issue, we will recommend to reset or re-install the CWA.

I hope, you can follow and support the logic of our agreement too. If so, I suggest closing this issue here in GitHub.

[MikeMcC399]

@GisoSchroederSAP

I will follow your suggestion to close this issue, since your support statistics say that the issue only occurs rarely. In addition, when 2.27 is released the problem should no longer occur at all if users update to the latest version.