Infinitely enabled override display issue in Nightscout

[mylma]

Describe the bug When infinitely enabled override is temporarily edited to have an ending time, Nightscout does not update the override label properly when the override has ended. Label indicating the override at he bottom of the BG graph was still visible after the override has ended. I tried to enact a cancel override command from NS and activated/ended any temp override from Loop, but the old override label was still visible in NS. Finally I deleted the override treatment from the mlab database to remove the incorrect override display. Also NS doesn't show any new activated override labels, only the old falsely active, when having this bug.

The override pill was working as it should, so this issue is related to override label only.

To Reproduce Steps to reproduce the behavior:

1. Enact infinitely enabled override in Loop.
2. Edit the active override to have an ending time and save.
3. Wait until the override has expired.
4. Nightscout override pill should show the correct info, but the override label under the BG graph is still visible indicating the infinite enabled override.
5. Try activate any override again. NS still shows the old infinite override as active.

Expected behavior Override label should have an ending point.

Screenshots

After I deleted the original treatment from the mlab, it looks like the Nightscout shows the override correctly... hmmm... Maybe the infinite enabled label was overlapping it...

Phone

• Hardware: iPhone SE
• OS Version: 12.4

Loop Version

• Version Number: Current dev
• Repo: Nonlinear carb model

Nightscout

• Version: 0.12.6-dev

[jgefaell]

• [ ] #1625 Are these two issues related?
• [ ] Is this a blocker for release?

with @bewest

[NightScoutForSeb]

This has been an issue for a while and the workaround is to not use infinite overrides. I know my friend Diliara just ran into this but I don’t believe there are many Loopers that use infinite overrides for their T1 children. I’d consider this a known issue worthy of a patch release fix, not a showstopper for release. Just my 2 cents.

Hanna SandovalSent from Yahoo Mail for iPhone

On Thursday, November 17, 2022, 11:22 AM, Jon Gefaell @.***> wrote:

• 1625 Are these two issues related?

• Is this a blocker for release?

with @bewest

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[bewest]

Thanks for the additional input, I was wondering how long this has been around. If the workaround is to avoid the feature, should the "indefinite duration" feature get cut out, so it never gets used? This is likely easier than fixing it. I've seen at least 3 of these verified recently; including your friend D getting her thread closed prematurely in FB groups. She's not the only one running into issues with this. :-)

[NightScoutForSeb]

Right, but the Duration field in Nightscout is not a required field, so how would you avoid infinite overrides from being submitted? I’d recommend to set overrides to 24h by default if no duration is provided, maybe? However, I don’t know if there are use cases to have overrides running for longer than 24h without user input. 

Hanna SandovalSent from Yahoo Mail for iPhone

On Thursday, November 17, 2022, 6:44 PM, Ben West @.***> wrote:

Thanks for the additional input, I was wondering how long this has been around. If the workaround is to avoid the feature, should the "indefinite duration" feature get cut out, so it never gets used? This is likely easier than fixing it. I've seen at least 3 of these verified recently; including your friend D getting her thread closed prematurely in FB groups. She's not the only one running into issues with this. :-)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[bewest]

As a strawman proposal, for clarity as a thought experiment: What I'm proposing is to eliminate or disable indefinite option from Loop rather than fix it. While it's old relative to dev, I don't think 2.2.9 exhibits this behavior? Sometimes it's healthy for a project to cut features, especially if they are thorny and rarely used and can speed the release.

[MikePlante1]

I‘d be very against removing indefinite overrides from Loop. This sounds like a Nightscout problem to me, not a Loop problem.

There are others, but one use-case for indefinite overrides is setting a target range below the 87 limit for correction range without customizing code.

[bewest]

Thanks for the additional input, can you explain a bit more about these use cases? With my developer hat on, this is a really challenging feature that is easily solved by putting a 24 hour or even 48 hour upper duration and requiring that everything has a duration. If there are other use cases that can't be met, it would be good to outline them.

For example, what if the same restriction for above 87 is also applied to overrides as well. I'm not saying this will happen or is proposed, but as a design experiment.

[MikePlante1]

Might a better solution be removing the ability to change a running OR from indefinite to having a time limit? The Looper could then just set a new OR with whatever time limit they want and sounds like it would avert the display issue in NS?

[Trpl7ca]

Well for example currently on a round of steroids which play havoc with Blood Sugar. I have an override set indefinitely for a lower target and find myself changing percentage of insulin needs several times during the day.  I suppose if limited to 24/48 hours could reset it as necessary but the indefinite setting works well for me with my current situation.On Nov 18, 2022, at 09:04, Ben West @.***> wrote: Thanks for the additional input, can you explain a bit more about these use cases? With my developer hat on, this is a really challenging feature that is easily solved by putting a 24 hour or even 48 hour upper duration and requiring that everything has a duration. If there are other use cases that can't be met, it would be good to outline them. For example, what if the same restriction for above 87 is also applied to overrides as well. I'm not saying this will happen or is proposed, but as a design experiment.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ps2]

We use indefinite ending (not infinite!) overrides when we suspect the situation to last for an unknown amount of time, and to experiment with new settings before adjusting them in therapy settings. Sometimes we'll run them for days. I don't think we want to remove this feature; I suspect it's fairly widely used.

[ps2]

Please check the stored records to see if Loop is updating the override record properly when it is finalized. If it's not, then file a Loop ticket, and I'll take a look. If it's updating the record, but NS isn't displaying it properly, then obviously the change will have to be on NS.

[bewest]

@ps2: Our testing team is unable to reproduce this issue. We think this was likely fixed either between versions of Nightscout or Loop since the original reporting. Should not be a blocker for releasing Loop, can recommend closing. If anyone is still experiencing this issue, please let me know so we can investigate as requested.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.