Infinite pull to refresh loop

[hummelstrand]

Describe the bug

It's possible to cause the forced loop function to not trigger.

Attach a Log

log.23.txt

log_prev.16.txt

To Reproduce

Dragging slowly or possibly up and down a few times causes the looping functionality to not trigger.

Expected behavior

Standard forced loop behavior.

Screenshots

Screen recording.
https://github.com/user-attachments/assets/abf4e07c-4e1b-4016-8a3d-ab899ecbd1a2

Setup Information (please complete the following information):

Smartphone:

• Hardware: iPhone 15 Pro Max
• OS Version: iOS 26.6

Pump:

• Manufacturer: Insulet
• Model: Omnipod Dash

CGM:

• Device: Dexcom G6
• Manager app: Dexcom App

Trio Version:

• Version Number: 0.8.4.58 (70)
• Repo: nightscout/trio
• Git Reference: commit hash 1c06086

Technical Details

Additional context

Love the pull to refresh functionality!

[g5WS]

I have seen the pull down to force loop not force loop as well. (Sorry, I am behind on bug entry.)

Also, note that the down arrow to the left of “pull down to force loop” seems to change direction with finger movement.

[dnzxy]

If it's not forcing the loop then that's usually the case because certain thresholds are not met (e.g., trying to force a loop 2 min after previous loop). Probably needs some kind of notification.

[g5WS]

If it's not forcing the loop then that's usually the case because certain thresholds are not met (e.g., trying to force a loop 2 min after previous loop). Probably needs some kind of notification.

The 2-minute thing is part of the problem, IMHO. When you bolus from a shortcut, the bolus appears on the graph, but Trio doesn’t loop. This is a confusing state to users who log carbs through Shortcuts but open up Trio to get the dosing recommendations. The app “knows” about the carbs (and is able to plot them on the graph), but the algorithm does not. The UI becomes misleading. It takes extra awareness, patience, and focus to dose properly.

I end up spending a lot of time (cumulatively) waiting for those two minutes to pass.

[dnzxy]

I don't think I'm following that, sorry. You are mentioning bolusing and carb entry, and not looping. Not exactly sure what's doing what for you in that context, could you elaborate please?
You bolus and then it doesn't loop, as in, you issue a large bolus? That'd be intentional behavior, as only an "algorithm output" (i.e. a determination) that gets acted upon makes a loop be considered complete. If it's not that then I'm not following the issue, but it may also not be what I was mentioning here.

What I meant by 2min is this: You can only force a loop after 3min in, so during minute 4 and later. If you pull down 2min after the latest loop, it won't loop, as the loop cannot be enacted that shortly after.

[LiroyvH]

I suppose it'd help if an alert banner would pop-up (or use the bottom banner thingy for it) informing the user that last loop was too recent to force a new one? Would that be possible? Now it just doesn't loop without giving a reason why, the user so happens to have to know the time limit and whether enough time has passed or not since the last attempt.

[g5WS]

I think the better solution is to allow refresh at any time.

When a user enters carbs through Shortcuts (and I imagine insulin as well, but I haven’t tested it), the graph updates immediately. A user would reasonably conclude that the system “knows” about the carbs/insulin. However, the algorithm does not know about the carbs/insulin until the next loop. This makes the algorithm’s recommendations inaccurate until the next loop kicks off.

Maybe Trio doesn’t need to loop, exactly, but it should never provide inaccurate dosing information.

♦️⬆️ Observe 0g COB. ♦️ ⬆️ Observe 0 units of insulin recommended. ♦️ ⬆️ Log 100g carbs through shortcuts. ♦️ ⬆️ Observe graph “knows” about the 100g of carbs. ♦️ ⬆️ Observe that the insulin calculation is unchanged. 😬. The algorithm does not acknowledge the carbs logged until the next loop.

This means users have to wait up to two minutes before they know how much to bolus. It’s a real pain for those that bolus meals via external insulin.

[dnzxy]

@g5WS that's an issue completely unrelated to the one we are discussing here. Please open a new issue for that, and specifically describe the path of entry therein. It's just missing a run of the meal module after adding carbs through shortcuts. Completely unrelated to the new design and the pull-to-loop interaction.

Looping at any given moment – i.e. forcing a loop always – does not make sense algorithmically, because the algorithm won't be able to enact insulin doses in such rapid succession, so those loops would never complete anyways. Or in other words, we're not allowing you to force algo behavior for UX comfort.