fix(azure/dashboard): reconcile committed figure with Coverage tab

[cristim]

Problem

The app owner reported on the live GUI: the Home page graph's current / committed figure for Azure showed $166, while the Coverage tab showed ZERO coverage for Azure. The same Azure subscription cannot both have active committed spend and zero coverage.

Repro

• Home dashboard "Current / Committed" (Azure) renders by_service[svc].current_savings, sourced from aggregateActiveCommitmentsPerService which sums each active commitment's EstimatedSavings (always populated) -> shows $166.
• Coverage tab (GET /api/inventory/coverage) summed only the recurring MonthlyCost, guarded by if p.MonthlyCost != nil.

Azure all-upfront RIs carry MonthlyCost == nil (no recurring charge at the commitment layer; documented on config.PurchaseHistoryRecord.MonthlyCost). So every Azure all-upfront row was silently dropped, the provider collapsed to Services=nil / OverallCoveragePct=nil, and the frontend rendered "No usage detected" -> ZERO. Meanwhile the dashboard still counted the same commitment.

Root cause

getCoverageBreakdown (internal/api/handler_inventory.go:184) ignored the upfront component entirely and skipped nil-MonthlyCost rows. PR #1105 only fixed the recommendation converter's RecurringMonthlyCost for future rows; it never touched the Coverage handler, so the divergence persisted (not deploy-lag — confirmed against committed origin/feat/multicloud-web-frontend).

Fix

Introduce a shared commitmentCoveredMonthly helper computing the effective covered monthly spend = recurring MonthlyCost (when present) + amortised upfront (UpfrontCost / (Term * MonthsPerYear)). This mirrors the canonical effective-monthly formula already used by analytics.Collector (the dashboard's savings analytics) and exchange_lookup, so the two surfaces agree on what "covered" means.

• All-upfront commitments now contribute their amortised upfront instead of being dropped.
• A nil MonthlyCost is treated as a real $0 recurring component, not a fabricated total (no silent fallback; absent != 0 distortion).
• Term <= 0 is guarded against division by zero, matching analytics.Collector's skip-bad-term defence.

The dashboard chart (savings) and Coverage tab (covered spend) measure different quantities by design and remain distinct numbers, but the actual defect - Azure silently dropping to zero coverage while the dashboard counts active commitments - is resolved: Coverage now reflects the same active Azure commitments.

Tests

TestHandler_getCoverageBreakdown_AzureAllUpfrontConsistency seeds an active Azure compute all-upfront RI (MonthlyCost nil, $1200 upfront / 1y term = $100/mo) and asserts:

• the dashboard primitive aggregateActiveCommitmentsPerService counts it ($166 savings);
• the Coverage tab reports $100/mo covered and 100% coverage for azure:compute, not nil/zero.

Fails pre-fix (azure.Services nil -> "No usage detected"), passes post-fix. go build ./... green; go test ./internal/api/ ./internal/analytics/ ./internal/purchase/ all green (2015 tests). No frontend change required - the UI already renders covered_monthly correctly once it is non-zero.

Summary by CodeRabbit

• Bug Fixes
  • Fixed coverage reporting for upfront cost commitments to accurately calculate and display coverage percentages. Upfront costs are now properly amortized across commitment terms for correct coverage calculations in inventory dashboards.

[cristim]

@coderabbitai review

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 7fd67d3d-f25b-4562-a625-c58cec229804

📥 Commits

Reviewing files that changed from the base of the PR and between 61788c1 and 0650a88.

📒 Files selected for processing (2)

• internal/api/handler_inventory.go
• internal/api/handler_inventory_test.go

---

📝 Walkthrough

Walkthrough

Coverage breakdown calculation for active commitments now properly handles all-upfront purchases by amortising upfront costs into monthly equivalents, fixing prior zero-coverage cases where MonthlyCost was nil. A new commitmentCoveredMonthly helper adds recurring and amortised upfront components; aggregation and documentation are updated accordingly.

Changes

Coverage Breakdown Upfront Amortization

Layer / File(s)	Summary
Amortized upfront cost helper and aggregation internal/api/handler_inventory.go	New commitmentCoveredMonthly helper computes covered monthly spend from MonthlyCost (or $0 if nil) plus UpfrontCost amortised over Term years using analytics.MonthsPerYear. Coverage aggregation uses this helper instead of only summing non-nil MonthlyCost. Doc comment updated to describe amortised upfront behavior. internal/analytics import added.
All-upfront coverage consistency test internal/api/handler_inventory_test.go	TestHandler_getCoverageBreakdown_AzureAllUpfrontConsistency validates Azure all-upfront commitments with nil MonthlyCost are correctly marked active and reported as covered with amortized monthly amounts, zero on-demand, and 100% coverage percentage.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• LeanerCloud/CUDly#760: Initial per-provider coverage breakdown implementation that getCoverageBreakdown's upfront-amortized covered fix builds upon.
• LeanerCloud/CUDly#881: Prior modification to getCoverageBreakdown logic for coverage scoping via provider/account filtering.

Poem

🐰 A rabbit hops through upfront costs so tall,
No more zero coverage for commitments all!
Monthly amortised, the math now clear,
Every dollar of commitment shines this year. 🌟

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title accurately describes the main fix: reconciling a discrepancy between the dashboard's committed figure and the Coverage tab for Azure all-upfront commitments.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/azure-committed-coverage-consistency

---

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

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.