[IAmJSD]

The failed-fetch half of this issue was handled by #1186. The other half remained: the Home "Upcoming Scheduled Purchases" widget ignored the Provider and Account chips, so with Provider = AWS it still listed Azure purchases. This PR applies the provider chip client-side and adds a note that the account chip does not apply to this widget, since the rows carry no account and the endpoint takes no filter parameters.

Refs #713
Partial: account scoping needs filter parameters on GET /api/dashboard/upcoming (backend), after which the frontend can pass the chip state and drop the note.

What changed

• New frontend/src/lib/upcoming-scope.ts:
  • scopeUpcomingToProvider() filters rows by the provider chip (empty or "all" keeps everything, case-insensitive).
  • upcomingEmptyMessage() names the provider when the filter empties the list.
  • UPCOMING_ACCOUNT_SCOPE_NOTE.
• frontend/src/dashboard.ts renderUpcomingPurchases(): applies the provider scope (the Retry path goes through the same renderer), builds the empty state with DOM calls instead of innerHTML, and when an account chip is active and rows exist, shows a muted note above the cards. The View Details index is built from the scoped rows.
• New src/__tests__/dashboard-upcoming-scope-713.test.ts.

Why this approach

The API rows already carry provider, so provider scoping is a correct, standalone frontend change. Account scoping cannot be done client-side, and getUpcomingPurchases (internal/api/handler_dashboard.go) takes no filter parameters. Rather than send query params the backend ignores and guess the future contract, the widget says the account filter does not apply, which removes the silent disagreement. The new logic lives in a small lib module because dashboard.ts is already about 1300 lines.

Screenshots

Before is main (a14dc8f2), after is this branch. Both are headless Chromium at 1440x900 against the repo's mocked e2e API. The chips are set via the URL (?provider=...&account=...); KPI tiles and charts are hidden in the shots only so the chips and the widget fit in one frame.

Before	After

1. Provider = AWS and Account = AWS Prod: before, the widget still lists the Azure VM reservation with no hint that the account chip is ignored. After, only the AWS rows remain and a muted note says the account filter does not apply here.
2. Provider = GCP: before, the widget lists AWS and Azure purchases. After, it shows "No upcoming scheduled purchases for GCP".

Verification

Run on this branch's head 210de5c7 on top of main a14dc8f2.

• npm run lint: 0 errors (142 pre-existing warnings, none in changed files). Typecheck and build pass.
• Jest: 110 suites, 3495 passed, 1 skipped. New dashboard-upcoming-scope-713.test.ts: 9 tests (helpers, plus the loadDashboard render path with no chips, provider chip, provider with no matches, account note, account plus empty, Retry applying the scope); also passes with --randomize.
• Playwright: 157 passed. No new e2e spec, since this is data scoping and jest drives the real render path.
• Secrets scan clean, planted key flagged. scripts/test-git-secrets-allowlist.sh: 137 PASS, 0 FAIL.

Notes for review

• Backend follow-up: add filter parameters to GET /api/dashboard/upcoming (for example provider and account_ids, as /dashboard/summary takes), then pass the chip state from the frontend and remove the note.
• Copy to check: "The account filter does not apply here: showing upcoming purchases for all accounts you can access." and "No upcoming scheduled purchases for GCP".
• A row's provider is the plan's first service provider (upcomingFromExecution), so a hypothetical multi-provider plan would be filtered by that one provider.

Overlaps

• fix(frontend): getUpcomingPurchases declares an array but the API returns { purchases } #1189's branch edits the same getUpcomingPurchases call sites in dashboard.ts. git merge-tree shows a clean merge (it aliases the UpcomingPurchase type that lib/upcoming-scope.ts imports, which stays compatible), but they should land one after the other.
• fix(frontend): Potential Monthly Savings differs between Home and Opportunities for the same recommendations #180's branch conflicts textually in dashboard.ts. fix(frontend): undefined button classes and grey default button break the button system #695's branch edits the Cancel button in the same renderer (trivial conflict). fix(frontend): impossible/placeholder values surfaced for scheduled and pending purchases #181's branch merges cleanly.

Note for the UI owner

This changes UI code that @cristim owns. IAmJSD reviewed the before/after screenshots and asked for it to be merged; any design point you disagree with can be a follow-up.

🤖 Generated with Claude Code

[coderabbitai]

Caution

Review failed

The pull request is closed.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

[IAmJSD]

Independent review (IAmJSD's agent, fresh context, given only the diff, the issue and the PR text): APPROVE b1d794c1386ba33913bd70db45f765e61eefac28

Blocking:

• none
  Non-blocking:
• frontend/src/lib/upcoming-scope.ts:37-41: upcomingEmptyMessage() repeats the provider formatting in buildFilterDesc() (frontend/src/dashboard.ts:76, provider && provider.toLowerCase() !== 'all' then toUpperCase), which predates the branch. The two can drift, e.g. if one starts mapping 'azure' to 'Azure'. Could use buildFilterDesc(provider, []) or share isProviderFilter.
• frontend/src/dashboard.ts:458-465: the PR drops the old !purchases || guard. This is safe today because both callers (dashboard.ts:189 and :437) pass data?.purchases || [], but scopeUpcomingToProvider() spreads its input, so a future caller that passes the nullable UpcomingPurchasesResponse.purchases (typed UpcomingPurchase[] | null since fix(frontend): type getUpcomingPurchases as the { purchases } envelope #1397) directly would throw instead of showing the empty state.
  Attacked: Diffed origin/main...HEAD (3 files: the lib module, the renderUpcomingPurchases hunk and the new test). HEAD^2 == origin/main 19534fc and merge-tree is clean. For all 4 merges (2b46c45, 69e4c74, 6b7ee6d, b1d794c), git diff <merge>^2 <merge> is exactly the same 3-file/215+/4- PR diff, so none of main's changes were dropped: fix(dashboard): include the year in the savings-trend tooltip title #1323/feat(frontend): show a sparse-data state on the savings trend chart #1334 chart-utils imports, fix(frontend): one money formatter and placeholder, right-align money #1376 formatter, fix(frontend): type getUpcomingPurchases as the { purchases } envelope #1397 envelope typing, #1400 cancel-own gate and fix(frontend): make the Home row Cancel an outlined destructive button #1359 outlined Cancel are all intact in the renderer. The empty state, note and badge use DOM calls and textContent, with no innerHTML on API data. View Details uses the scoped index. Retry re-reads the chip at render time. Chip changes re-run loadDashboard through the existing subscriptions. No duplicate listeners.

[IAmJSD]

Local verification at b1d794c1 merged onto current main (19534fca; merge-tree 7a7ab058; Linux, Node, headless Chromium):

• This branch's own checks passed at this head: lint, typecheck, build, the full jest suite, the full Playwright e2e suite, and the git-secrets checks (see Verification in the PR body).
• The combined tree of every UI PR in this merge wave (tree ab77aa6e, main plus 5 PRs) passes npm ci, lint, typecheck, build, jest (1 skipped, 4248 passed, 4249 total), and the full Playwright suite (247 passed).
• CI is green on b1d794c1 (CI Success, Run pre-commit hooks).
• The independent review above approves this exact head.
• Nothing was applied to any cloud.

[IAmJSD]

Marked ready and merged by IAmJSD's agent, at IAmJSD's request (IAmJSD reviewed the before/after screenshots; cristim is traveling), after the independent review and local verification above, all at b1d794c1.