-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LOOP-887 Keycloak updates and DIY Sync #560
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nit] why not use the warning Interval to calculate timeUntilNotification
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I worry about this change. If the lastLoopDate
was not now, timeUntilNotification
should be used, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just to track which warning it was (20m/40m/etc) for forensics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah... yup. I agree
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
checkVersion
protocol).