Dangerous overestimation of COB after extended carbs entry, as if entry was doubled

[planiitis]

AAPS version 3.3.2.1
Glucose sensor: Freestyle Libre 3+ via Juggluco (1-minute interval!)
Pump: Omnipod Dash
Using closed loop with SMB enabled in Simple mode

• 12:16:19: Starting with no COB recorded, I made an extended carbs entry of 70 g with a time offset of -10 min and a duration of 1 h.
• 12:16:46: I used the calculator to perform a bolus, based on BG, COB and IOB. COB at this point was 16.4 g.
• 12:17: AAPS set temp basal to 0.00U/h (it remained at 0.00U/h until 15:58).
• 12:20–14:40: AAPS kept giving SMBs, keeping the glucose level in range (peak of 9.6 mmol/l at around 13:00). With some exceptions between 12:29 and 13:01, every SMB was delivered at 5 minute intervals, at either xx:x0 or xx:x5.
• 12:51: Peak recorded COB at about 45 g. Graph shows four individual peaks spaced 15 minutes apart.
• 14:56: The glucose level started dropping rapidly and I started getting warnings about up to 42 g additional carbs required. Looking at the history graph, at this point the BG was at around 8 mmol/l the COB was at 0 g, while the IOB was very high: enough to reduce the BG further by about (IOB * ISF) = 15 mmol/l or absorb about (IOB * IC) = 55 g of carbs.
• 15:06: I noticed something very troubling:
  • Suddenly the COB had jumped from zero to 57 g, and the history graph showed a peak of 114 g at around 12:56. The graph also showed twice as many peaks, as if the extended carbs entry had duplicated and shifted by 5 minutes.
  • At the next refresh a few seconds later it was all back to normal again, showing 0 g COB with a peak at about 46 g at 12:46.

It seems that the calculated COB has been repeatedly switching between the proper amount and one based on a duplicated carbs entry, effectively giving up to twice as much insulin via SMB as it should. It actually keeps switching between the correct and the wrong COB as I'm writing this at 17:00 UTC.

There's a very specific pattern: The wrong calculation happens every 5 minutes, at xx:x0 or xx:x5, then reverts to the correct one at the next recalculation one minute later. Some sort of off-by-one error somewhere?

This is of course a serious safety concern and needs to be fixed. I'll see if I can provide relevant log data. I have disabled SMB on my instance for now (while SMB is not the cause here, it does make the issue worse).

[planiitis]

I was going to extract the logs today, but apparently the log file cleanup logic is bugged and deletes "old" log files in alphabetical order instead of chronological order, which is different. I only have files AndroidAPS._2025-12-23_00-00-21_.3.zip through ...9.zip and ...20.zip through ...28.zip. The relevant period started at ...19.zip or earlier, which apparently got deleted because 19 is before 3 alphabetically. Go figure.

[planiitis]

From screenshots of the 6-hour graph that I took before and after a recalculation at 15:06:

Bad COB graph calculated at 15:05, showing eight peaks during the 1h 70 g extended-carb period, with a final peak at 114 g:

Correct COB graph calculated at 15:06, showing four peaks during the 1h 70 g extended-carb period, with a final peak at 46 g:

[MilosKozak]

so no logs available?

[planiitis]

No logs of this particular incident. I am currently trying to reproduce the necessary conditions for the bug to appear.

I just did an extended carbs entry, 20 g with time offset -10m and duration 1h. The entry was made at 10:26:18, while the carbs are recorded as starting at 10:15:05. Not seeing any duplication so far.

Looking at the entries from the incident on the 23rd, I see that while the extended carbs entry was made on 12:16:19, the carbs were recorded as starting at 12:06:00. Could a necessary condition be that this is exactly on the minute boundary?

[planiitis]

I've managed to reliably reproduce the bug. The steps are as follows:

1. On the Overview screen, within the first second of any minute on the clock, e.g. at exactly 12:34:00, press the Carbs button. The dialog should appear before the first second has passed.
2. Set Duration to 1 h and Carbs to e.g. 20 g. Time offset is not necessary to trigger the bug, but can be set to e.g. -1 h to make the bug appear faster.
3. Press OK and confirm the entry.
4. The graph should show four "5 g" carb events spaced 15 minutes apart.
5. On the Treatments screen, check the user entries to confirm that the carbs were registered as starting within the first second of the minute, The entry should show something like "31/12/2025 12:34:00 20g".

Assuming the numbers are recalculated around the 30th second of each minute, then starting about 9.5 minutes after the time of the first carb event (i.e. around 12:43:30 in the example above) and every 5th minute following that, the calculation will produce a COB graph where every intended carb peak has a duplicate peak 5 minutes later, resulting in twice as many carb peaks as there should be and a COB value that is too high. On the following recalculation one minute later, the COB graph and value is correct again.

I don't know exactly how things behave with a 5-minute sensor interval. It may be possible to trigger the bug even then, if the recalculations happen on the correct minute.