Repository navigation
api: fetchCommitmentPurchases swallows store errors into zeroed dashboard KPIs #72
Description
Found during the LeanerCloud/cloud-commitments-cli#1221 pre-merge review (pre-existing, not introduced there): handler_dashboard.go's fetchCommitmentPurchases logs store errors but returns zeroed commitment KPIs ("log error but don't fail") - a silent fallback on a money-visible path. A store outage silently shows $0 active commitments / committed-monthly on the dashboard instead of an error state. Fix: propagate the error (or an explicit degraded marker the frontend renders as unavailable, never 0). Per feedback_no_silent_fallbacks / nullable-not-zero.
Activity
cristim commentedon Jul 28, 2026
Reviewed commit:
be11bdcb5. Note:origin/mainmoved to3e9660d06during the review; re-verify against currentmainbefore changing code, since a finding may have been fixed or moved.Re-derived independently during the 2026-07-28 full review of
internal/apiand confirmed still live onbe11bdcb5. Recording as evidence, plus one compounding effect the issue does not mention.Where, on current line numbers:
internal/api/handler_dashboard.go:634-643(fetchCommitmentPurchases), consumed at:678-683. On aGetActivePurchaseHistoryerror the function logs"KPIs will be zeroed"and returns(nil, false);calculateCommitmentMetricsthen returns0, 0, 0, niland the handler ships a 200.The compounding effect.
calculateCurrentCoverage(internal/api/handler_dashboard.go:738) returns100.0wheneverpotentialSavings == 0. So a store error that zeroes the commitment half, occurring alongside a recommendations shortfall that zeroes the potential-savings half, renders "100% coverage, $0 committed": internally self-consistent, entirely fabricated, and reassuring rather than alarming. An operator with 400 active commitments sees a headline of zero commitments and zero YTD savings on a Monday-morning dashboard load, with a coverage figure that appears to confirm nothing needs buying.Whichever fix is chosen (propagate the error, or an explicit degraded marker), the
potentialSavings == 0branch ofcalculateCurrentCoverageshould be addressed in the same change, otherwise the degraded state still renders a confident 100%.Sibling from the same review:
internal/api/handler_inventory.go:224-230has the same silent-fallback shape with a different wrong value. There, a failedListRecommendationsleavesonDemandByKeyempty andcoveragePct(covered, 0)computescovered/(covered+0)*100 = 100, so the Coverage tab renders 100% for every provider/service row. It is recorded in the grouped medium/low issue forinternal/apifrom this review; the two are worth fixing together since they share the "zero is not the same as unknown" requirement (feedback_no_silent_fallbacks/ nullable-not-zero).