The Savings-over-time analytics chart (getSavingsAnalytics -> /history/analytics, and getSavingsBreakdown -> /history/breakdown) accepts only account_id + date range + interval. getHistoryAnalytics/getHistoryBreakdown read NO provider param, and QueryHistory/QueryBreakdown WHERE is timestamp >= $1 AND timestamp <= $2 [+ account dual-column clause] (they GROUP BY provider but never restrict to one). So selecting a single Provider in the global top-bar filter does NOT filter the Savings History chart.
QA row 305 (LeanerCloud/cloud-commitments-cli#701) expects a Provider selection to filter Approval Queue + Savings History + Purchase History. The Approval Queue and Purchase History lists DO honor the provider filter; the Savings History chart does not. Account filtering of the chart works (fixed by LeanerCloud/cloud-commitments-cli#956). This gap is pre-existing - the analytics path never took a provider param; LeanerCloud/cloud-commitments-cli#956's scope was the account-id (UUID vs external) representation bug.
Fix
Plumb provider into getHistoryAnalytics/getHistoryBreakdown -> QueryHistory/QueryBreakdown WHERE (AND provider = $n when set), and have the FE getSavingsAnalytics/getSavingsBreakdown forward the global provider chip. Add a test asserting a provider-only selection restricts the chart. If an all-providers trend is the intended UX, close as wontfix with a note.
Found during adversarial verification of LeanerCloud/cloud-commitments-cli#956 (zero-ambiguity confirm of the analytics provider-only case).
Findings from the 2026-09-02 codebase audit
Added by an automated audit of 3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd (tip of origin/main). Each item below was reported by one reviewer and independently confirmed by a second that did not write it. Full report: docs/audits/codebase-audit-2026-09-02.md.
A11-014 (medium)
The account dimension has the same shape as the provider gap described here, and the fix should probably land together. getSavingsAnalytics (frontend/src/api/history.ts:43-45) sends both account_ids=a,b,c and account_id=a, but the analytics handlers read only the singular param (accountID := params["account_id"] at internal/api/handler_analytics.go:40, :131, :197, then resolveSingleAccountFilterIDs) and account_ids is parsed nowhere for these routes. So with three accounts selected the chart silently renders only account A's savings while the chip row advertises three, an under-reported figure with no indication that two were dropped. The sibling getHistory (history.ts:22) sends only the plural form, which internal/api/handler_history.go:678 does honour, so the two panels on the same page disagree for the same filter. Either plumb account_ids through the analytics path alongside provider, or have the caller disable/annotate the chart when more than one account is selected. Audit finding A11-014.
The Savings-over-time analytics chart (
getSavingsAnalytics->/history/analytics, andgetSavingsBreakdown->/history/breakdown) accepts onlyaccount_id+ date range + interval.getHistoryAnalytics/getHistoryBreakdownread NOproviderparam, andQueryHistory/QueryBreakdownWHERE istimestamp >= $1 AND timestamp <= $2 [+ account dual-column clause](they GROUP BY provider but never restrict to one). So selecting a single Provider in the global top-bar filter does NOT filter the Savings History chart.QA row 305 (LeanerCloud/cloud-commitments-cli#701) expects a Provider selection to filter Approval Queue + Savings History + Purchase History. The Approval Queue and Purchase History lists DO honor the provider filter; the Savings History chart does not. Account filtering of the chart works (fixed by LeanerCloud/cloud-commitments-cli#956). This gap is pre-existing - the analytics path never took a provider param; LeanerCloud/cloud-commitments-cli#956's scope was the account-id (UUID vs external) representation bug.
Fix
Plumb
providerintogetHistoryAnalytics/getHistoryBreakdown->QueryHistory/QueryBreakdownWHERE (AND provider = $nwhen set), and have the FEgetSavingsAnalytics/getSavingsBreakdownforward the global provider chip. Add a test asserting a provider-only selection restricts the chart. If an all-providers trend is the intended UX, close as wontfix with a note.Found during adversarial verification of LeanerCloud/cloud-commitments-cli#956 (zero-ambiguity confirm of the analytics provider-only case).
Findings from the 2026-09-02 codebase audit
Added by an automated audit of
3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd(tip oforigin/main). Each item below was reported by one reviewer and independently confirmed by a second that did not write it. Full report:docs/audits/codebase-audit-2026-09-02.md.A11-014 (medium)
The account dimension has the same shape as the provider gap described here, and the fix should probably land together.
getSavingsAnalytics(frontend/src/api/history.ts:43-45) sends bothaccount_ids=a,b,candaccount_id=a, but the analytics handlers read only the singular param (accountID := params["account_id"]at internal/api/handler_analytics.go:40, :131, :197, thenresolveSingleAccountFilterIDs) andaccount_idsis parsed nowhere for these routes. So with three accounts selected the chart silently renders only account A's savings while the chip row advertises three, an under-reported figure with no indication that two were dropped. The siblinggetHistory(history.ts:22) sends only the plural form, whichinternal/api/handler_history.go:678does honour, so the two panels on the same page disagree for the same filter. Either plumbaccount_idsthrough the analytics path alongsideprovider, or have the caller disable/annotate the chart when more than one account is selected. Audit finding A11-014.