[sbalint]

Summary

LoopUnit.conversionFactor applies a duration-style time factor (×1/60 for seconds → minutes) to the four conversions that change both the glucose unit and the time unit. Rates convert in the opposite direction, so each of these was off by 3600×:

Conversion	Was	Should be
mg/dL·s → mmol/L·min	1/UMM / 60	1/UMM * 60
mg/dL·min → mmol/L·s	1/UMM * 60	1/UMM / 60
mmol/L·s → mg/dL·min	UMM / 60	UMM * 60
mmol/L·min → mg/dL·s	UMM * 60	UMM / 60

The same-glucose-unit rate cases (mg/dL·s → mg/dL·min) were already correct, and the scalar cases (mg/dL → mmol/L) were already correct. Only the mixed conversions were wrong, so only mmol/L users were affected.

User-visible impact

Most visibly this broke the carb effect chart. Insulin counteraction effects are stored in mg/dL·s and CarbEffectChart requests them in <glucose unit>/min, so for mmol/L users the observed series rendered 3600× too small and collapsed onto zero — while the predicted carb effect series, which never uses a rate unit, rendered correctly. The chart looked like the algorithm had failed to observe any carb absorption at all.

Dosing is unaffected. The algorithm paths stay in mg/dL throughout and never hit a mixed conversion. This is a display-layer bug only.

Background

These four cases were previously grouped two-per-case, with each group pairing opposite glucose directions under one shared factor. fa581b3 ([LOOP-5162] unit conversion fix) split them so each pair gets its own glucose factor — correct — but the /60 and *60 time factors were carried over from the old groupings and ended up attached to the wrong pairs. The accompanying test updates encoded the new values, so the suite has passed against the inverted factors since.

Test plan

• The existing tests asserted the same incorrect factors, so the suite passed against the bug. Those assertions are corrected.
• testConversionFactorsMatchHealthKit now checks every unit pair against HealthKit's own dimensional analysis, so the table cannot silently drift again.
• Full suite: 183 tests, 0 failures against current main (9628dfe).
• Verified in the Loop app in mmol/L: the observed carb absorption series now tracks the predicted series instead of sitting at zero.

🤖 Generated with Claude Code

[ps2]

Thanks for tracking this down! The fix is right, and checking the whole table against HealthKit is a great guard. I confirmed the new test fails on exactly the four bad pairs with the old code and passes with the fix.