Fix duplicate xDrip bolus treatments - #158
Conversation
Follow-up to the earlier timestamp/duplicate fix on dev. Two issues turned up on real-device testing after that landed: - CurrentBolusStatusRequest is polled repeatedly (often once/second) while the bolus confirmation dialog is open, and every poll of the same in-flight bolus was still creating its own xDrip dose entry -- the earlier fix only deduped exact repeats of an identical (bolusId, status) pair, not the distinct REQUESTING/DELIVERING/ terminal states a single bolus normally passes through. - Gating the broadcast on the bolus reaching a terminal status doesn't work either: that polling is scoped to the confirmation dialog's lifetime and commonly stops (dialog dismissed, app backgrounded) before the pump ever reports a terminal state, so the entry silently never got sent at all. requestedVolume on CurrentBolusStatusResponse is the bolus's requested amount, fixed at request time rather than a running delivered-so-far tally, so the first status poll already carries the correct figure. Now broadcasts once, on the first poll per bolusId, and ignores bolusId=0 (which means "no active bolus"). InitiateBolusResponse keeps broadcasting as before -- it carries no insulin/carbs field, so xDrip's own Treatments.noteOnly() renders it as a separate note-only graph marker rather than a dose entry, so it was never actually part of the duplicate-dose problem.
|
@mcurly here's the proper fix for the duplicate issue, with screenshot of an end to end test on my actual xdrip #157 |
Hi, @ahaverty ! I am sorry for not having returned here more promptly. I will try your commit in a while. I was out during the weekend. Thank you a bunch for your work! Both of you! Cheers! ☀️ |
|
@ahaverty , ok, checked it out. Look please at these pictures: 
So, thank you! I confirm on my side it's fixed! Wow! Cheers! ☀️ |
2 participants
Follow-up to the earlier timestamp/duplicate fix on dev. Two issues turned up on real-device testing after that landed:
CurrentBolusStatusRequest is polled repeatedly (often once/second) while the bolus confirmation dialog is open, and every poll of the same in-flight bolus was still creating its own xDrip dose entry -- the earlier fix only deduped exact repeats of an identical (bolusId, status) pair, not the distinct REQUESTING/DELIVERING/ terminal states a single bolus normally passes through.
Gating the broadcast on the bolus reaching a terminal status doesn't work either: that polling is scoped to the confirmation dialog's lifetime and commonly stops (dialog dismissed, app backgrounded) before the pump ever reports a terminal state, so the entry silently never got sent at all.
requestedVolume on CurrentBolusStatusResponse is the bolus's requested amount, fixed at request time rather than a running delivered-so-far tally, so the first status poll already carries the correct figure. Now broadcasts once, on the first poll per bolusId, and ignores bolusId=0 (which means "no active bolus").
InitiateBolusResponse keeps broadcasting as before -- it carries no insulin/carbs field, so xDrip's own Treatments.noteOnly() renders it as a separate note-only graph marker rather than a dose entry, so it was never actually part of the duplicate-dose problem.
Physical device end to end test result:
