fix(overview): keep current-month snapshots live and query Tenant kind correctly

[tym83]

Summary

The /api/overview endpoint currently freezes the current-month snapshot at the first request of the month. For April 2026 this has been returning 43 clusters / 164 nodes / 83 tenants since April 1, while live VictoriaMetrics has climbed to 112 / 450 / 444 as of 2026-04-22.

Two bugs fixed:

1. Current-month snapshots are now regenerated on every request and never written to disk. Only final end-of-month snapshots are persisted. Non-final snapshots already on the PVC (e.g. the stale 2026-04.json from April 1) are ignored on load, so the existing file self-heals at month turnover.
2. total_tenants was always 0 because the scalar query used kind="tenant" while the emitted metric label is kind="Tenant" (see client code in cozystack/cozystack/internal/telemetry and docs v1/operations/configuration/telemetry.md). Fixed to match the real label.

What

• overview.go:
  • ensureSnapshot: for the current/future calendar month, skip memory+disk cache and always call collectSnapshot.
  • collectSnapshot: persist only when isFinalSnapshot(s); otherwise store in memory via the new storeSnapshotInMemory helper.
  • loadSnapshots + loadSnapshotFromDisk: skip non-final files so the legacy stale April file does not repopulate the cache.
  • saveSnapshot delegates the in-memory update to storeSnapshotInMemory (no behaviour change).
  • New helpers: isCurrentOrFutureMonth, isFinalSnapshot.
• Tenant query: kind="tenant" → kind="Tenant".

Why

Without this fix every current-month snapshot reflects whatever VM reported at the first request that month — frozen until the month ends. The website fetches this endpoint daily and exposes the stale number on cozystack.io/oss-health/telemetry/. The Tenant-label bug hid behind a workaround in the website fetcher that reads apps.Tenant instead of total_tenants; that workaround still works after this fix and can be dropped in a follow-up.

Operational note

After deployment the stale 2026-04.json on the PVC stays, but is no longer read (isFinalSnapshot = false). On May 1 a correct end-of-April snapshot will be generated and overwrite it. No manual cleanup needed.

Test plan

• go build ./... and go vet ./... pass (done locally)
• Deploy to staging; request /api/overview?year=2026&month=04 twice and confirm the response tracks live VM, not a frozen value
• Request a past month (e.g. ?year=2026&month=03) and confirm it stays cached
• Verify total_tenants is non-zero and matches sum(cozy_application_count{kind="Tenant"})
• After 2026-05-01, confirm April snapshot on disk has been regenerated with CollectedAt past end of April

[coderabbitai]

Warning

Rate limit exceeded

@tym83 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 59 minutes and 38 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 59 minutes and 38 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 67d4ff77-8114-485d-9f33-d1127dde9018

📥 Commits

Reviewing files that changed from the base of the PR and between e2bb204 and a51ffbb.

📒 Files selected for processing (1)

• overview.go

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/current-month-live-and-tenant-label

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request introduces logic to distinguish between final and non-final snapshots, ensuring that data for the current month is always fresh and not persisted to disk. The review identifies two significant issues: the implementation bypasses the singleflight mechanism for the current month, which will cause redundant network queries, and the in-memory cache check for past months does not distinguish between final and non-final snapshots, potentially serving stale data until the service is restarted.

[gemini-code-assist]

The current implementation of ensureSnapshot has two significant issues:

1. Singleflight Bypass: For the current month, it calls collectSnapshot directly and returns (lines 110-115). This bypasses the singleflight logic, meaning that multiple concurrent requests for the current month will trigger redundant, expensive network queries to VictoriaMetrics and GitHub.
2. Stale Memory Cache: For past months, the check if m.hasSnapshot(monthLabel) (line 117) returns true even if the in-memory snapshot is a non-final one from when the month was still in progress. This prevents the snapshot from ever being finalized (loaded from disk or regenerated) until the service is restarted.

I recommend refactoring the logic to use singleflight for all regenerations and ensuring that only final snapshots are used as a cache for past months.

	if !m.isCurrentOrFutureMonth(monthLabel) {
		m.mu.RLock()
		hasFinal := false
		for _, s := range m.snapshots {
			if s.Month == monthLabel && isFinalSnapshot(s) {
				hasFinal = true
				break
			}
		}
		m.mu.RUnlock()
		if hasFinal {
			return
		}

		// Try loading from disk cache before querying VM.
		if m.loadSnapshotFromDisk(monthLabel) {
			return
		}
	}