-
Notifications
You must be signed in to change notification settings - Fork 497
CWA risk update timestamp different to Google timestamp (by one or two minutes) #948
Comments
Hello @MikeMcC399, thanks for pointing this out. I will take this into the discussion with our development team. Best regards, Corona-Warn-App Open Source Team |
Hello @MikeMcC399 , thanks again for your investigation. Our developers have been informed. This bug probably occurs due to different rounding strategies and will be inspected as soon as possible. Best regards, Corona-Warn-App Open Source Team |
I noticed the Google Exposure Notification Framework (Version 15202902003) showing a time one minute into the future. |
People who already read some of my comments in this repository, may know, that I'm sometimes doing some wild guesses about the source of a problem, sometimes more elaborate, sometimes less... Hope, no-one is bothered about that. If yes, please leave a note. May it be, that CWA's timestamp is being set upon beginning checking for exposures, and ENF's timestamp at completion of checks? Edit: that was the more less elaborate guess... |
Just some curiosity to report mirrored from over at #1187 (comment) My EN log entry today: I.e. my CWA timestamp is one minute after my EN timestamp. Maybe in my case it's a rounding error by ENF in the other direction? As long as the time difference doesn't exceed 1 min I won't be able to tell for sure I guess but it's also not that important tbh ^^ My device:
|
@daimpi I checked on one device I own and I'm also seeing the CWA timestamp one minute later than the EN timestamp, on another device the timestamps are identical. Both are updated to CWA 1.5.0 and I guess the change in which comes first is due to the version change from 1.3.1 to 1.5.0 and the replacement of 14 entries with just one entry per day (when things are working correctly). I've therefore updated the title to say the timestamps are different without saying which way around. |
The timestamp in the CWA on the card is set after the key retrieval & submission is done by the app. It's possible that it's a racecondition. Theoretically the ENF can finish calculation before we store the timestamp, and we can also set the timestamp before the ENF does finish calculation. I have not looked into any rounding related issues, but I'm looking into changing the displayed timestamp to be "ENF calculation end" instead of "key provision to the ENF". The ENF displaying a timestamp newer than the actual device time looks like rounding (on purpose?) on Google's side. Did it exceed 1 minute for anyone? |
Just for me speaking, on my slow phone, ENF timestamp was always after CWA timestamp. At the moment CWA's timestamp is 2 minutes before ENF's. Snail race condition, imho. ;) Edit: And I never saw device time before ENF timestamp.
Did you already do something concretely? I was thinking about coding a proposal for that as an excercise, maybe till middle/end of next week, depending on my own workload. If you already have a progress on that issue, I'd skip beginning anything. |
I mean the discrepancy between the ENF log and the device clock (#948 (comment)).
I'm already working on a set of classes that will be accessible via the I hope to solve 3 issues by making this class available to other parts of the app:
Hope to create a PR today. Feedback on that is welcome 👍. |
Yes, yes, I got it after submitting the comment :)
Ehm, my proposal would have been... let's say, a little bit more simple. Happily awaiting your first class dinner, and skipping to cook a scrambled egg then ;) |
The issue of slightly differing timestamps is still apparent in CWA Android 1.7.1. App shows: Google exposure log shows: The previous timestamps in the Google exposure log for today were: 28 November 2020, 13:00 |
Currently still waiting on an answer from Google, previous solutions still were off by a few minutes, so we can't continue on this unless Google tells us what the timestamp represents and how it's calculated on their end 🙁 . |
... or Google extends their API to share their timestamp, so that all UIs are using the same value. |
Just throwing my 2ct in ... If the root cause is different rounding of the same timestamp, then it would indeed be less confusing to have this aligned. But if the root cause is that the timestamps refer to different phases in the background check (e.g. Google shows when their API was called / begin of check, and cwa shows when the check was successfully finished) - in such a case different timestamps could give more information for troubleshooting, like: what was the total duration of the check? Was there a check that was started but then aborted? |
Just to mirror some info relevant to this issue provided by @d4rken here:
|
@MikeMcC399 Is this beaviour still happening in 2.2 ? Corona-Warn-App Open Source Team |
Yes, the issue has never been resolved and it still occurs in CWA Android 2.2.1 Probably it would need changes made to the Google interface so that the exact timestamp is passed back to the calling COVID-19 app, such as CWA. |
Looks like we have to ask Google again for input. |
I made two different observations:
|
Same observation that I made in #948 (comment) almost one year ago, so it looks like Google didn't change anything there. |
@MikeMcC399 why should Google make a fix? |
And I have no problems with different timestamps at all. It seems to be confusing, so it should be explained to the users, that the meaning of these timestamps is indeed 'different things'. Something along the lines:
|
@d4rken / @heinezen
Then in May 2021
Was there ever any effective response from Google on this subject? It's already been stated that the issue can't be resolved without Google's help, so if there is no expected movement around a discussion with Google then I would suggest closing this issue and writing a short FAQ article explaining that the timestamps in the app and in the Google UI may be different. |
I have not heard anything back from Google on this topic. |
I didn't have that in mind anymore... yes, so nothing changed after one year. Even this issue might get closed, just one addition for the records:
seems not to be completely correct, after I checked some old data. So, to be able to align the CWA and ENS timestamp, CWA would need to be able to know, when ENS found the files... |
@ndegendogo 😄 |
@vaubaehn sure 😁😁 And I am amused how diligently you are analysing the log files |
Despite @vaubaehn's amazing analysis and detective work, this issue can't be solved without the assistance of Google and according to the comments in this issue Google has not responded in over 9 months. The best solution would have been for Google to pass back their timestamp via API, so there would have been no guesswork or inaccuracies. I have no hope that this will ever happen though. So now I'm closing this issue. |
Avoid duplicates
Describe the bug
The last update time shown by CWA is sometimes one minute or two minutes earlier or later than the update time shown in the Google ENS UI.
Expected behaviour
This is a minor issue.
The timestamp shown by CWA for the last update should be the same as the timestamp shown in the Google ENS UI in the overview screen and in the exposure checks log.
Steps to reproduce the issue
Note text similar to "Updated: Today, 07:54"
Note latest timestamp in exposure checks list.
Technical details
1.1.12.4.215202902003v1.8 (212116000)Edit: Updated steps to reproduce for newer ENS UI, updated software versions and verified that the issue still occasionally occurs in current version of CWA and ENS.
Internal Tracking ID: EXPOSUREAPP-1991
The text was updated successfully, but these errors were encountered: