Background
Discovered while fixing #498: the frontend's loadSavingsTrendChart()
reads state.getCurrentProvider() but does NOT pass it to
getSavingsAnalytics(...) because the backend handler
(internal/api/handler_analytics.go::getHistoryAnalytics) does not
honour a provider query param — it only takes account_id
(documented as an Athena limitation).
As a result, switching the Provider chip on the Home page does not
truly filter the Savings-over-time chart. What happens today: the
topbar-filters.ts provider-change handler clears the account
selection (per the #185 ordering rule), which fires the account
subscriber, which triggers loadDashboard() → loadSavingsTrendChart()
with no account_ids → backend returns "all accessible accounts".
The chart shape changes (because we reset to All) but isn't actually
provider-filtered.
The user report in #498 captured this as the "Provider-filter caveat"
(row 2.2): "graph adjusts. Can't confirm if data itself is correct."
What to do
Wire provider through the analytics handler:
internal/api/handler_analytics.go::getHistoryAnalytics reads
provider from params (currently only reads account_id and
interval).
- Pass
provider to analyticsClient.QueryHistory(...) — extend the
client signature if needed.
- The Postgres query in
analyticsClient.QueryHistory filters by
provider when present (additive to the existing account_id
filter).
- Frontend (
dashboard.ts::loadSavingsTrendChart +
modules/savings-history.ts::loadSavingsHistory) starts passing
provider: state.getCurrentProvider() to getSavingsAnalytics.
- Regression test: a request with
provider=aws&account_id= returns
only AWS rows; a request with provider=aws&account_id=acct-X
returns only AWS rows for acct-X.
Acceptance criteria
- Backend
/history/analytics?provider=aws returns AWS-only data
points; ?provider=gcp returns GCP-only.
- Provider chip change on the Home page produces visibly different
chart data when the underlying analytics history contains rows from
multiple providers.
- Existing single-account-only queries continue to work (backward
compatible).
Background
Discovered while fixing #498: the frontend's
loadSavingsTrendChart()reads
state.getCurrentProvider()but does NOT pass it togetSavingsAnalytics(...)because the backend handler(
internal/api/handler_analytics.go::getHistoryAnalytics) does nothonour a
providerquery param — it only takesaccount_id(documented as an Athena limitation).
As a result, switching the Provider chip on the Home page does not
truly filter the Savings-over-time chart. What happens today: the
topbar-filters.tsprovider-change handler clears the accountselection (per the #185 ordering rule), which fires the account
subscriber, which triggers
loadDashboard()→loadSavingsTrendChart()with no
account_ids→ backend returns "all accessible accounts".The chart shape changes (because we reset to All) but isn't actually
provider-filtered.
The user report in #498 captured this as the "Provider-filter caveat"
(row 2.2): "graph adjusts. Can't confirm if data itself is correct."
What to do
Wire
providerthrough the analytics handler:internal/api/handler_analytics.go::getHistoryAnalyticsreadsproviderfromparams(currently only readsaccount_idandinterval).providertoanalyticsClient.QueryHistory(...)— extend theclient signature if needed.
analyticsClient.QueryHistoryfilters byproviderwhen present (additive to the existingaccount_idfilter).
dashboard.ts::loadSavingsTrendChart+modules/savings-history.ts::loadSavingsHistory) starts passingprovider: state.getCurrentProvider()togetSavingsAnalytics.provider=aws&account_id=returnsonly AWS rows; a request with
provider=aws&account_id=acct-Xreturns only AWS rows for acct-X.
Acceptance criteria
/history/analytics?provider=awsreturns AWS-only datapoints;
?provider=gcpreturns GCP-only.chart data when the underlying analytics history contains rows from
multiple providers.
compatible).