Nightscout only retains ~4 days of treatments (entries go back 140+ days) — investigate MongoDB retention/disk #13

New Issue

2026-07-31T12:33:52Z

willemjan commented

2026-07-31 12:33:52 +00:00

Not a dashboard bug — filed here because it directly limits the reporting feature's trend/bolus/site-age stats (Trends page, PDF export), unlike issue with entries pagination (fixed in PR #12) which was a client bug.

Finding (verified 2026-07-31 by paginating the real API with find[date][$lte] cursors, bypassing any client-side truncation):

/api/v1/entries/sgv.json: real data goes back at least to 2026-03-13 (40 full pages of 1000, ~140 days, still not exhausted — stopped testing there, consistent with the instance having been set up over the winter).
/api/v1/treatments.json: data starts at 2026-07-27 and nothing exists before it — confirmed by requesting find[date][$lte] progressively further back; the response is empty past that point, not just short. This isn't the pagination bug (that only affected how much of a period the client asked for in one request); this is the server genuinely not returning anything older, for treatments specifically.

So CGM entries (uploaded via xDrip+, per docs/requirements-reporting.md's described setup) retain full history, but treatments (uploaded via AndroidAPS — temp basals, boluses, site/sensor changes) only retain ~4 days. This directly explains why Trends (bolus stats, site-interval stats) and any FR8 pump-site-age analysis over a 90-day period will only ever have ~4 days of insulin data to work with, regardless of the entries fix in PR #12.

Hypotheses, not yet confirmed (need shell/DB access I don't have — see below):

A MongoDB TTL index or capped collection specific to treatments, possibly left over from a low-disk-space mitigation.
A Nightscout PURGE_ENABLED/purge-related env var configured for treatments but not entries.
Disk space on the VM (nightscout, VM 105, 192.168.2.12, 30GB disk) is tight and something (manual or scripted) is pruning the larger/faster-growing treatments collection (AAPS writes treatments very frequently — temp basals every ~5 min — so this collection likely grows faster than entries despite being logically smaller per-document).

What's needed to actually diagnose this: SSH/console access to VM 105 to check docker-compose/env vars for the Nightscout + MongoDB containers, run db.treatments.getIndexes() / db.treatments.stats() in mongosh to check for a TTL index or capped-collection flag, and check df -h for real disk pressure. I don't have credentials for this VM (it's outside the LXCs the CI/CD deploy key is authorized on) — flagged to the user directly, not something I can self-serve.

On the "do we even want years of retention" question: agreed this doesn't need indefinite retention — but 4 days is far below what's clinically useful (the reporting feature's own consensus targets, Danne et al. 2017, assume at minimum a 14-day analysis window, with 90-day quarterly views also standard). Worth deciding on an intentional retention policy (e.g. keep 1 year, purge older) rather than whatever is currently happening by accident.

**Not a dashboard bug** — filed here because it directly limits the reporting feature's trend/bolus/site-age stats (Trends page, PDF export), unlike issue with entries pagination (fixed in PR #12) which *was* a client bug. **Finding (verified 2026-07-31 by paginating the real API with `find[date][$lte]` cursors, bypassing any client-side truncation):** - `/api/v1/entries/sgv.json`: real data goes back **at least to 2026-03-13** (40 full pages of 1000, ~140 days, still not exhausted — stopped testing there, consistent with the instance having been set up over the winter). - `/api/v1/treatments.json`: data **starts at 2026-07-27 and nothing exists before it** — confirmed by requesting `find[date][$lte]` progressively further back; the response is empty past that point, not just short. This isn't the pagination bug (that only affected how much of a period the *client* asked for in one request); this is the *server* genuinely not returning anything older, for treatments specifically. So CGM entries (uploaded via xDrip+, per docs/requirements-reporting.md's described setup) retain full history, but treatments (uploaded via AndroidAPS — temp basals, boluses, site/sensor changes) only retain ~4 days. This directly explains why Trends (bolus stats, site-interval stats) and any FR8 pump-site-age analysis over a 90-day period will only ever have ~4 days of insulin data to work with, regardless of the entries fix in PR #12. **Hypotheses, not yet confirmed (need shell/DB access I don't have — see below):** 1. A MongoDB TTL index or capped collection specific to `treatments`, possibly left over from a low-disk-space mitigation. 2. A Nightscout `PURGE_ENABLED`/purge-related env var configured for treatments but not entries. 3. Disk space on the VM (`nightscout`, VM 105, 192.168.2.12, 30GB disk) is tight and something (manual or scripted) is pruning the larger/faster-growing `treatments` collection (AAPS writes treatments very frequently — temp basals every ~5 min — so this collection likely grows faster than `entries` despite being logically smaller per-document). **What's needed to actually diagnose this:** SSH/console access to VM 105 to check `docker-compose`/env vars for the Nightscout + MongoDB containers, run `db.treatments.getIndexes()` / `db.treatments.stats()` in `mongosh` to check for a TTL index or capped-collection flag, and check `df -h` for real disk pressure. I don't have credentials for this VM (it's outside the LXCs the CI/CD deploy key is authorized on) — flagged to the user directly, not something I can self-serve. **On the "do we even want years of retention" question:** agreed this doesn't need indefinite retention — but 4 days is far below what's clinically useful (the reporting feature's own consensus targets, Danne et al. 2017, assume at minimum a 14-day analysis window, with 90-day quarterly views also standard). Worth deciding on an intentional retention policy (e.g. keep 1 year, purge older) rather than whatever is currently happening by accident.

willemjan commented

2026-08-01 19:42:33 +00:00

Resolved — root cause found, no server-side change needed.

Got SSH access to the nightscout VM (105, 192.168.2.12) and checked MongoDB directly:

treatments collection: 123,165 documents, capped: false, no TTL index (getIndexes() shows 17 plain indexes, none with expireAfterSeconds). Oldest document dates back to 2025-07-29 — the full year of history is sitting right there in the database.
entries: 80,857 documents, same story, no capping/TTL.
Disk: / is at 87% (11G/14G used, 1.8G free) — worth keeping an eye on generally, but not the cause of this issue and not urgent given the above.

So this was never a retention/disk/Mongo problem — it's another Nightscout API quirk, this time genuinely server-side (unlike the client-side pagination bug fixed in PR #12):

/api/v1/treatments.json filters/sorts on the string field created_at, not the numeric date field that /api/v1/entries uses. Filtering on find[date][$lte] (or supplying no filter at all) silently limits treatments to an internal ~4-day window, even though every document has a perfectly valid date field. Filtering explicitly on find[created_at][$lte] — confirmed by hand against the live instance — correctly pages back through the full 123k+ document history.

Fixed in nightscout_client.py: _paginated_get() now takes an explicit cursor_field per endpoint ("date" for entries, "created_at" for treatments) and always sends the cursor explicitly, even on the first page, so that hidden default window is never triggered. Verified against the real instance: fetch_treatments_range for a 92-day window now returns 39,403 rows (was ~700 before the fix). New regression tests added specifically pinning the created_at field choice so this can't silently regress.

Closing — no Nightscout/Mongo config or disk cleanup needed for this specific problem. Disk usage is a separate, lower-urgency thing to keep an eye on.

**Resolved — root cause found, no server-side change needed.** Got SSH access to the `nightscout` VM (105, 192.168.2.12) and checked MongoDB directly: - `treatments` collection: **123,165 documents**, `capped: false`, no TTL index (`getIndexes()` shows 17 plain indexes, none with `expireAfterSeconds`). Oldest document dates back to **2025-07-29** — the full year of history is sitting right there in the database. - `entries`: 80,857 documents, same story, no capping/TTL. - Disk: `/` is at 87% (11G/14G used, 1.8G free) — worth keeping an eye on generally, but **not the cause of this issue** and not urgent given the above. So this was never a retention/disk/Mongo problem — it's another Nightscout API quirk, this time genuinely server-side (unlike the client-side pagination bug fixed in PR #12): **`/api/v1/treatments.json` filters/sorts on the string field `created_at`, not the numeric `date` field that `/api/v1/entries` uses.** Filtering on `find[date][$lte]` (or supplying no filter at all) silently limits treatments to an internal ~4-day window, even though every document has a perfectly valid `date` field. Filtering explicitly on `find[created_at][$lte]` — confirmed by hand against the live instance — correctly pages back through the full 123k+ document history. Fixed in `nightscout_client.py`: `_paginated_get()` now takes an explicit `cursor_field` per endpoint (`"date"` for entries, `"created_at"` for treatments) and always sends the cursor explicitly, even on the first page, so that hidden default window is never triggered. Verified against the real instance: `fetch_treatments_range` for a 92-day window now returns 39,403 rows (was ~700 before the fix). New regression tests added specifically pinning the `created_at` field choice so this can't silently regress. Closing — no Nightscout/Mongo config or disk cleanup needed for this specific problem. Disk usage is a separate, lower-urgency thing to keep an eye on.

willemjan closed this issue

2026-08-01 19:42:41 +00:00

willemjan referenced this issue from a commit

2026-08-01 19:43:13 +00:00

fix: treatments endpoint needs a created_at cursor, not date

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: willemjan/glucose-dashboard#13