Bug in 15.0.7 - doublicated Nightscout Profiles causing wrong COB/IOB display

[emp-00]

After several round of root cause checks with help of AI the conclusion is clear, this is a bug in NS 15.0.7. See the following description with the details. What can we do against this right now? For me this is severe issue - my IOB/COB display is always wrong leading to potentially wrong treatment decisions (I am not on a loop, but using classic insulin shots). THANKS for looking into this!!

A severe calculation bug has been identified in Nightscout instances running version 15.0.7 deployed via the Navid200 Google Cloud installation environment. The user-facing symptom is that Carbs on Board (COB) and Insulin on Board (IOB) tracking values are heavily multiplied immediately after a treatment is logged (for example, entering an 8g carb treatment instantly displays as 16g COB on the main dashboard). Deep analysis of the database structures reveals that the root cause is the accumulation of duplicate profile records inside the MongoDB profile collection, all sharing the exact same default fallback timestamp: Valid from: 1/1/1970, 1:00:00 AM.

This duplication completely breaks Nightscout’s mathematical tracking due to the core Profile API overhauls introduced in the v15 architecture. As documented in the official 15.0.7 release notes, while websocket-path profile deduplication is functional, the v3 REST-path profile-store deduplication was explicitly reverted (commit c927be7a) and remains a "Known Issue / Deferred." Because the web-based Profile Editor relies entirely on this REST path to save and delete records, users are trapped in a loop: any attempt to fix or delete the duplicate records via the browser UI fails to cleanly purge the database, and the conflicting "onion layers" of the 1970 profile simply reappear upon page reload, forcing the server to calculate active decay against multiple documents concurrently.

See here: https://github.com/nightscout/cgm-remote-monitor/releases

Profile save — replaceOne upsert prevents duplicate-key errors under concurrent saves (nightscout/cgm-remote-monitor#8455).
Websocket AAPS profile dedup — dbAdd for profiles dedups by startDate; insert errors now warn rather than crash (85f7e6ac).
Note: A v3 REST-path equivalent of the AAPS profile-store dedup (3b786ab3) was reverted (c927be7a) pending further validation. The websocket-path dedup remains.

Known Issues / Deferred
v3 REST AAPS profile-store dedup — Reverted in c927be7a; only the websocket dbAdd dedup ships in 15.0.7. Re-introduction tracked for a follow-up.

[Navid200]

@tzachi-dar This sounds like a Nightscout issue.
Could it be local to our (Google Cloud) setup only?

[Navid200]

Before I forget, thanks for reporting this.

Let's be as cautious as we can be:

1- Create a backup and download to your physical (not virtual ) computer: https://google-cloud-nightscout.github.io/docs/DatabaseBackup.html

2- Run phase 1.

Does the problem go away?

[psonnera]

@emp-00 do not wipe anything: follow @Navid200 's recommendations: I ran Phase 1 and the database and settings were untouched by this action. Better safe than sorry, backup before. I bet one beer (or any other non alcoholic drink) that it will fix your duplicates issue.

[emp-00]

@Navid200 / @psonnera Thank you both for taking all this time, this thread is breaking all records (SORRY!). I'm happy to help fixing any potential problem in the scripts, let me know if I should do some more diagnosis on my installation before I run phase 1. I'm now backing up the mongoDB, ready for phase 1.

[Navid200]

If you have backed up and transferred it to your computer, go ahead and run phase 1.

[emp-00]

@Navid200 @psonnera , you deserve the beer(s): Phase 1 did the job - it completed and my NS was back up right away, accessible via my sub-domain. I just entered 500 g carbs in xDrip and NO MORE DOUBLET is shown in NS (waited 2 minutes)! Then I deleted the test entry via xDrip and also here, NO MORE GHOST carbs remaining! Finally, COB (and I'm sure also IOB) seems to work correctly again! Chapeau guys, what can I do to order you the deserved ice-cold (alcohol-free) beer or whatever you prefer!?!

Fyi, GC NS status page looks 100% identical compared to before executing phase 1 (even disk space usage is 35% same as before! Only the NS proc number increased by +2, all other versions etcpp shown on the status page are unchanged). Tadaa, ya-hoo package.json 3.7.3 was updated to the version you wanted to see:

emp00@nightscout2025:~$ cd /srv/nightscout-vps
emp00@nightscout2025:/srv/nightscout-vps$ grep '"version"' node_modules/mongodb/package.json
  "version": "5.9.2",

We did it! Is there anything else you would like to test on my repaired GC NS installation? Shoot!

PS: Can you now explain why this happened? Murphy's law, it happened to me and nobody else - so be it :-)

[Navid200]

There is a bug in Google Cloud Nightscout.

Several packages like Mongo are installed running phase 1.
There is a verification phase when phase 1 starts that checks to see what it should do.
This phase was faulty resulting in skipping to re-install modified packages like Mongo.
We discovered this recently and fixed it.
But, in the meantime, there are many systems out there now with outdated Mongo.

What caused the real problem is that the way I check the Mongo version in the status page is obviously erroneous. So, your real Mongo was outdated. But, the status page did not detect it.

Solution:
I will be checking the status page code to make sure that it will accurately identifies the installed Mongo version.
After that is done, anyone who brings up the status page, will see a red marker for their Mongo version.
The key page will show that as a problem that will be resolved by running phase 1.

Thanks to @emp-00 for reporting this and working hard at it and having faith in us.
Thanks to @psonnera for coming to the rescue and figuring out the problem.

[emp-00]

Appreciate your explanations - helps a lot.

One last thing I still don't get - phase 1 updated "3.7.3" to "5.9.2" and fixed the doublet issues - but MongoDB is shown (on your status page) as "v8.0.17". This 3.X.X or 5.X.X must be something else but not Mongo? Sorry for the stupid question, I'm not into the (sub)-components that GC NS uses.

In any case, GC NS is work of geniuses - open-source and very reliable, have been using it for years. THANKS.

[Navid200]

There is a difference between the installed mongo database engine version and the version of drivers that are being used.
Our drivers are not the latest. We can update those at some point. But, these are two different things installed separately.

Throughout the life of the Google Cloud Nightscout project, we have always given priority to stability rather than having the latest and greatest.
So, if something is not broken and there is no security vulnerability, unless there is a deprecation warning somewhere, we have never gone out of our way to update everything to the latest. This is something that was in this project when it was born and we were told "stability matters".

I hope this makes sense.

[Navid200]

We have made a change to address this. It is now in our dev branch being tested. I expect in a week, it will be released.
This is what the status page will look like:

The Mongo line on the status page will show both the database version as well as the driver version.

Nightscout version 15.0.8 will be released shortly. That will be our next release. To update to a new version of Nightscout, everyone will have to run phase 1. I think that will fix the problem for everyone.

If anyone experiences problems in the future related to this, we will be able to see the driver version on the status page to detect this easier.

Thanks again for reporting this.