-
Notifications
You must be signed in to change notification settings - Fork 495
No matching performed if no new keys have been downloaded #4768
Comments
@fynngodau thanks for bringing this up. This was a deliberate decision at the time with the following reasoning: The current approach gives a high probability that if two devices show the same or similar last updated timestamp on the home screen/tab, that the respective risk was calculated based on the same data (i.e. same set of keys that was submitted to GMS). I'll try to illustrate what happens otherwise. Let's take your slightly modified example:
If task
As such complex explanations are not really helpful to the user, we discarded the idea and stuck with the current behavior. But we're open to reviewing this:
|
The I have no idea how many users are actually impacted by this and how big the impact is considering that at least evey 24h there will be a risk calculation. But to max out the ENF given quota is probably desireable to warn as early as possible (It probably could be a telemetry data point to see how many risk calculations were performed to see how much deviation from 6 there is, but that's another topic I presume) |
Describe the bug
For every run of the
DownloadDiagnosisKeysTask
, the following steps are performed as per the code:(4 hours as per config, unlike this comment suggests) or
This code appears to be faulty, because if new keys are already available in the app's cache during execution of this code, but no further new keys are available for download at the time of execution, then no keys will be handed over to GMS and one hour will be lost before the task is run again to downloads fresh diagnosis keys during its run, which it can then pass to GMS along with all other previously downloaded keys.
Steps to reproduce the issue
Suppose that, during a given hour in a day, an hourly package is not made available, or that the user is offline and therefore cannot retrieve it. Then consider the following diagram:
a
signifies a task that syncs keys but is then aborted because the most recent submission to GMS is too recent.b
signifies a task that syncs keys, but finds no new ones and therefore aborts – even though keys that had not yet been submitted to GMS are available in cache.s
signifies a task that successfully finds new keys and submits them to GMS.The same condition could happen if a user opens the app after an hourly package is made available, but before the minimum interval is up.
Expected behaviour
The task should correctly detect new keys by checking for keys that had not been provided to GMS, not just for freshly downloaded keys.
Additional context
This bug was found by @Elsensee.
The text was updated successfully, but these errors were encountered: