Conversation
Release 2.2.4
…into loop-release/v2.2.5
Loop release v2.2.5
Bring in LoopKit updates for 2.2.6 patch
…keys to watch extension plist
Updated translations from Lokalise on Mon Mar 20 12:48:17 CDT 2023
| let failureInterval = lastLoopDate.addingTimeInterval(.minutes(minutes)).timeIntervalSinceNow | ||
| guard failureInterval >= 0 else { break } | ||
| let warningInterval = TimeInterval(minutes: minutes) | ||
| let timeUntilNotification = lastLoopDate.addingTimeInterval(.minutes(minutes)).timeIntervalSinceNow |
There was a problem hiding this comment.
[nit] why not use the warning Interval to calculate timeUntilNotification?
There was a problem hiding this comment.
Looking at the other changes, I don't understand this change. I think it created 2 potential issues and if those are issues it is not used until line 220.
| timeInterval: failureInterval, | ||
| timeInterval: warningInterval, |
There was a problem hiding this comment.
I worry about this change. If the lastLoopDate was not now, timeUntilNotification should be used, correct?
There was a problem hiding this comment.
This is just to track which warning it was (20m/40m/etc) for forensics.
There was a problem hiding this comment.
Then the name should be updated to reflect this. At least to me it doesn't read this way.
There was a problem hiding this comment.
The Loop not looping warning has several different time intervals that it is triggered at, so a warningInterval seems like a descriptive name for that. Or is it something else that you are wanting to make clearer? Open to suggestions.
There was a problem hiding this comment.
I'm looking at timeInterval for the StoredLoopNotRunningNotification. I'm not sure how this is used, so it is hard to suggest an alternative. If this is not used, then just remove it. If it is needed, then its need will guide the name. timeInterval is too general and allows the reader to make false assumptions.
There was a problem hiding this comment.
It just keeps track of the particular time interval of this particular Loop not looping notification, so it seems like it's accurately named to me?
There was a problem hiding this comment.
Removed this variable, which changes the serialized format of StoredLoopNotRunningNotification, which will potentially cause some historically issued alerts to not be recorded in the alert store is issued, affecting forensics, but not safety.
| if let failureIntervalString = formatter.string(from: failureInterval)?.localizedLowercase { | ||
| if let failureIntervalString = formatter.string(from: warningInterval)?.localizedLowercase { |
There was a problem hiding this comment.
I think this change is incorrect and believe it should be timeUntilNotification. Should the copy be updated to in at least %@?
There was a problem hiding this comment.
Say that lastLoopDate was 15 minutes ago. The "20 minute" loop not looping alert should go off in 5 minutes. So timeUntilNotification should be five minutes. But the failure string should still indicate that it has been "20 minutes" since the last loop.
| let failureInterval = lastLoopDate.addingTimeInterval(.minutes(minutes)).timeIntervalSinceNow | ||
| guard failureInterval >= 0 else { break } | ||
| let warningInterval = TimeInterval(minutes: minutes) | ||
| let timeUntilNotification = lastLoopDate.addingTimeInterval(.minutes(minutes)).timeIntervalSinceNow |
There was a problem hiding this comment.
Looking at the other changes, I don't understand this change. I think it created 2 potential issues and if those are issues it is not used until line 220.
nhamming
left a comment
There was a problem hiding this comment.
I didn't detect anything. Same question though. Is there good test coverage for these updates? If not, considering adding.
Keycloak changes ticket - https://tidepool.atlassian.net/browse/LOOP-887
DIY Sync ticket - https://tidepool.atlassian.net/browse/LOOP-4610
This is the Loop portion of the DIY sync, including keycloak updates.
Main changes:
checkVersionprotocol).