Twitter report: Warn others does not work "Es konnte keine Übermittlungs-TAN erstellt werden."

[Ein-Tim]

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

Technical details

• Device name: Pixel 4a
• Android version: 12
• App version: 2.17.2

Describe the bug

The Twitter user requested a TAN via the TAN hotline, entered it in the app and stepped through the "Warn others" process. However, at the very end, he sees this error message:

Steps to reproduce the issue

1. Request a TAN at the hotline
2. Enter the TAN
3. Step through the Warn others process
4. See the error at the end of the process

Expected behaviour

No error.

Additional context

Clicking on "Details" reveals this stack trace:

Ursache:
de.rki.coronawarnapp.exception.TanPairingException: Tan has been retrieved before for this registration token
	at de.rki.coronawarnapp.playbook.DefaultPlaybook.submit(DefaultPlaybook.kt:29)
	at de.rki.coronawarnapp.playbook.DefaultPlaybook$submit$1.invokeSuspend(Unknown Source:12)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:4)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:18)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:10)
Caused by: de.rki.coronawarnapp.exception.http.BadRequestException: Error during web request: code=400 message= body='
	at de.rki.coronawarnapp.http.HttpErrorParser.intercept(HttpErrorParser.kt:36)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:14)
	at de.rki.coronawarnapp.http.interceptor.RetryInterceptor.intercept(RetryInterceptor.kt:3)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:14)
	at okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.kt:5)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:14)
	at de.rki.coronawarnapp.http.interceptor.WebSecurityVerificationInterceptor.intercept(WebSecurityVerificationInterceptor.kt:3)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:14)
	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:25)
	at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:12)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
	at java.lang.Thread.run(Thread.java:920)

This is a Twitter report

The information in this report is based on the feedback from a Twitter user: https://twitter.com/kaugummiheld/status/1491100030589345792?s=20&t=4awuiciEbF56ti451dKT6Q. He said the TAN was entered into the app 2 minutes after he got it from the hotline.

---

Internal Tracking ID: EXPOSUREAPP-11782

[vaubaehn]

It looks to be the same problem, that has already been reported one year ago. Because at that time the error dialog wasn't specific enough, the dialog was enhanced in https://github.com/corona-warn-app/cwa-app-android/pull/2161 . What I understood from @mtwalli 's explanation is, that a user got a TAN from hotline, but when CWA tried to retrieve a token for that into CWA entered TAN from the web server, the web server couldn't find such a token. It's unclear why the token can't be retrieved, but it looks like, CWA can't do anything about it.

Personally I would think it would be worth to try again after 5 or 10 minutes (maybe there is just a delay in the server infrastructure), but if it fails again, a new TAN would need to be generated by the hotline.

But in any way: respect that the user got a TAN at all!

[svengabr]

Internal Tracking ID: EXPOSUREAPP-11782

[Ein-Tim]

@vaubaehn

He tried it multiple times on different dates. Should I suggest to get a new TAN?

[vaubaehn]

@Ein-Tim In that case, I recommended to do so. Hope there's not much waiting time in the TAN hotline...

[vaubaehn]

@dsarkar @mtwalli The dialog text recommends to call the technical helpline... What is supposed how they can help in that case?

[Ein-Tim]

@vaubaehn

Okay, I suggested to call the hotline again. Is there really nothing what the app can do in this case?

[vaubaehn]

@vaubaehn

Okay, I suggested to call the hotline again. Is there really nothing what the app can do in this case?

@Ein-Tim I don't think that anything on CWA side can be done technically (although it's worth to re-evaluate the dialog text/whether the technical help line can actually help), but I would forward this question to @mtwalli to be sure.

[vaubaehn]

@dsarkar Do you know wether there is a plausibility-check of the entered TAN-code (like a one-digit 'Prüfsumme' inside the TAN-code itself) before CWA trying to retrieve the corresponding token on the server? If there is no such check, a simple typo (or misunderstood letter/number when read by the call center agent to the user) could cause this error, couldn't it?

[vaubaehn]

@dsarkar I cross-checked whether there is a checksum calculation for the TAN. And there is. The last digit is the checksum, and simple alteration of the last digit it's possible to create a theoretically valid TAN. However, using such a self-created TAN results in a different error ("TAN invalid or already used. Call TAN hotline for information").

This means, a simple typo or misunderstood letter/number cannot lead to the error reported above in OP.

However, it's still unclear for me whether the current recommendation to call the technical helpline is of any value in the case of a failed pairing of TAN and token.

[Ein-Tim]

@vaubaehn

Probably, all what the technical hotline can do to help you, is redirect you to the verification hotline.

[Ein-Tim]

@svengabr @dsarkar @thomasaugsten @larswmh

Do we have an incident here?

Also see a Twitter user reporting this: https://twitter.com/timm_1991/status/1504100365171634179?s=21

Reports from users of CCTG: https://codeberg.org/corona-contact-tracing-germany/cwa-android/issues/213#issuecomment-401411

FYI @fynngodau

[citizenserious]

@vaubaehn

Probably, all what the technical hotline can do to help you, is redirect you to the verification hotline.

After 20 minutes waiting in the verification hotline someone picked up and immediately hang up, so that is no help either.

[dsarkar]

@citizenserious Thanks for your comment, we will forward this to the corresponding entities.

[Ein-Tim]

Another Twitter user having the same problem: https://twitter.com/_derTheoretiker/status/1514536930494623750?s=20&t=KQceXEF8eDkHhoJylWdcPg

He already tried it with separate TANs issued from the hotline but always receives this error. I asked him for an error log.

@thomasaugsten FYI

[Ein-Tim]

Here's the error log: CWA Log 2022-04-14 18_33_24.372.txt

[Ein-Tim]

@mlenkeit Hey Maximilian, just a friendly reminder, maybe you or the team could take a look at the error log I shared above.

[dsarkar]

@Ein-Tim error log forwarded to internal ticket. Thanks!

[mlenkeit]

@Ein-Tim thanks for sharing the log! I'm afraid the timeframe that is covered by the log is too short. We would need a log that captures what a sufficient amount of time before the error occurs. Ideally, the entire time frame from when the positive test result is received until the errors occurs. Realistically, this means users would need to turn error logging on before registering a test.

[Ein-Tim]

@mlenkeit

Thank you for your feedback! Okay, that's not so cool, as no user will just activate error logging every time before registering a test. I guess you & the team are trying to reproduce this issue yourself?

[Ein-Tim]

Here's another report on this: #5248.

The strack trace @FrederikP shared via https://github.com/corona-warn-app/cwa-app-android/issues/5248#issuecomment-1142016804 looks very similar to the one I posted in the OP.

[dsarkar]

@Ein-Tim @FrederikP Thanks, case linked in internal ticket.

[Ein-Tim]

@mlenkeit

This seems to be a quite common problem:

• https://twitter.com/count_tofu/status/1534923746359771138?s=21&t=rmW6bZnxXiCpYFICMUE1bg
• https://twitter.com/wasserspeierdd1/status/1534930834326704128?s=21&t=rmW6bZnxXiCpYFICMUE1bg

[mlenkeit]

We picked up the analysis of this issue again and here is some information:

The error message (Es konnte keine Übermittlungs-TAN erstellt werden) is displayed for the following scenarios:

1. the network call to obtain an Upload TAN from the Verification Server fails with status code 400 It seems like this can only happen through CWA if the Upload TAN is requested multiple times. And this again typically happens when there is a poor network connection.
2. the network call to upload the Diagnosis Keys to the cwa-server fails with status code 400 It seems like this can happen through CWA for a number of reasons such as:
   • Country list out of sync
   • Device time in the future
   • wrong days since onset of symptoms - an edge case that can happen when the uses chose today as onset of symptoms and the submission is done between midnight UTC and midnight local time

While 1) and 2) share the same error message, the technical exception text is different:

• the ones that we've seen here and in #5248 are caused by 1)
• we have not seen any reports on GitHub or Twitter from users experiencing 2)
• however, the server logs indicate that there is a very small number of users are affected by 2)

In case of 1), the current error message to call the Technical Hotline is not helpful. The only thing the user can do in that case is to call the TAN Hotline to get a new TAN. Here, we are working on adjusting the error message. A technical change to avoid this from happening altogether would require a larger architectural redesign which is currently not possible.

In case of 2), there is nothing the user can do to fix this. We considered just suppressing the error message in that case, but then we wouldn't become aware of such problems. Instead, we plan to stick with the current error message (i.e. call the technical hotline) but also to adjust the cwa-server to be more permissive/lenient, such that error message should never be displayed.

Please note that these changes will not make it into 2.24.

[mlenkeit]

Here are some related PRs for cwa-server:

• https://github.com/corona-warn-app/cwa-server/pull/1849
• https://github.com/corona-warn-app/cwa-server/pull/1854

[Ein-Tim]

Hey @mlenkeit,

thank you for providing links to these PRs!

I have a Twitter report (Link to the Tweet which includes screenshots from the app), from a user with

• Device name: Huawei p20 pro
• Android version: Android 10
• App version: CWA 2.14.1

who receives the error "Es konnte keine Übermittlungs-TAN erstellt werden." with the following stack trace:

Ursache:
de.rki.coronawarnapp.exception.TanPairingException: Tan has been retrieved before for this registration token
at de.rki.coronawarnapp.playbook.DefaultPlaybook.wrapException(DefaultPlaybook.kt:131)
at de.rki.coronawarnapp.playbook.DefaultPlaybook.submit(DefaultPlaybook.kt:114)
at de.rki.coronawarnapp.playbook.DefaultPlaybook$submit$1.invokeSuspend(Unknown Source:15)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at http://kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)
Caused by: de.rki.coronawarnapp.exception.http.BadRequestException: Error during web request: code=400 message= body='
at de.rki.coronawarnapp.http.HttpErrorParser.intercept(HttpErrorParser.kt:80)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
at de.rki.coronawarnapp.http.interceptor.RetryInterceptor.intercept(RetryInterceptor.kt:15)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
at okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.kt:154)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
at de.rki.coronawarnapp.http.interceptor.WebSecurityVerificationInterceptor.intercept(WebSecurityVerificationInterceptor.kt:11)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:517)
at java.util.concurrent.ThreadPoolExecutor.runWorker(http://ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(http://ThreadPoolExecutor.java:641)
at http://java.lang.Thread.run(https://t.co/PHlVTUItSA)

The user said he tried warning others one time, at the end of the process there was an error message reg. missing internet connection and now he is not able to warn others because of the error with the stack trace I posted above.

The acute question for this user is now: Did the app already warn others or should I call the TAN hotline to get a TAN?

cc @thomasaugsten

[mlenkeit]

Did the app already warn others or should I call the TAN hotline to get a TAN?

@Ein-Tim it depends on the details of the missing internet connection error message. From this information it's difficult to tell.

With a TAN from the TAN hotline, we would ensure that the warning is shared (given that the upload goes through then).

[Ein-Tim]

@mlenkeit

The stack trace of the missing internet connection message is lost, sadly.

I'll tell the user to delete the old test and request a TAN at the hotline, just to be on the safe side.

Thanks for your fast response.

[dsarkar]

FYI This PR is intended to improve the situation: https://github.com/corona-warn-app/cwa-app-android/pull/5335

[mlenkeit]

Another PR somewhat related to this problem is #5384

[mlenkeit]

We hope that https://github.com/corona-warn-app/cwa-app-android/pull/5335 fixes this issue for good. The fix will most likely be included in 2.26.