[IAmJSD]

Root cause

GET /api/dashboard/upcoming (getUpcomingPurchases, internal/api/handler_dashboard.go) took no query parameters. It returned every pending execution the session's allowed_accounts could see, so the Home "Upcoming Scheduled Purchases" widget couldn't follow the topbar provider and account chips that the rest of Home sends to /api/dashboard/summary. #1186 already fixed the error state. #1365 then applied the provider chip in the browser and added a "the account filter does not apply here" note, because the rows carry no account. As cristim's comment on the issue says, the open part is backend filter parameters plus the frontend sending the chip state. This PR is the backend part.

Fix

• getUpcomingPurchases now reads provider, account_ids and the legacy account_id. Validation and precedence match getDashboardSummary:
  • providerFilterParam: "" or all means every provider; anything else is a 400.
  • parseAccountIDs: a malformed list or more than 200 ids is a 400.
  • account_ids wins over account_id.
  • Both filters are parsed before any store read.
• The account selection goes through resolveDashboardAccountScope, the same resolver the summary uses. That resolver intersects it with the session's allowed_accounts, so the out-of-scope behaviour matches the other dashboard routes: an account outside the caller's scope is dropped, and a selection with no in-scope account matches no rows (200, empty list). It never widens the result. The existing per-row session check (isExecutionInScope) still runs first and is unchanged, so the filter can only remove rows.
• Matching rules (new internal/api/handler_dashboard_upcoming_filter.go):
  • Provider: compared with the row's provider, i.e. its plan's first service. That's the value the widget shows and the value fix(frontend): scope Home upcoming purchases to the provider chip #1365 filters on today.
  • Account: a row matches when any account its execution can buy in is selected, using the existing executionAccounts. A plan-level parent fans out to every plan account, so it matches when any of them is selected. A fan-out child (cloud_account_id set) matches only its own account.
  • Accounts match by UUID, or by external account number under their provider. The legacy account_id can carry a raw external number.
• With no parameters, or provider=all and an empty account_ids, the response is identical to main.
• The loop moved into upcomingInScope, following plannedPurchasesInScope, to keep getUpcomingPurchases under the gocyclo limit.
• internal/api/openapi.yaml documents the three parameters and the new 400 response on getUpcomingPurchases.

Refs #713

Concurrency

No DB writes, no migration and no new store method. The handler only reads (pending executions, plans, plan accounts, cloud accounts), the same set the summary and planned-purchases reads already use. There's no new race to test.

Verification

Unit/mock evidence: real handler code against MockConfigStore fixtures (four plans, five pending executions across Production, Staging and a GCP account, including a multi-account plan-level parent and its Staging fan-out child). One test also goes through HandleRequest with a query string, to cover the router wiring.

New tests in internal/api/handler_dashboard_upcoming_filter_test.go:

• TestGetUpcomingPurchases_NoFilterUnchanged: no parameters, and provider=all with an empty account_ids, both return every row. This test passes before and after, by design.
• TestGetUpcomingPurchases_ProviderFilter: gcp, aws and azure (empty).
• TestGetUpcomingPurchases_InvalidFilterIs400: unknown provider; non-UUID account_ids.
• TestGetUpcomingPurchases_AccountFilter:
  • a single account, including the multi-account parent but not the other account's child;
  • two accounts;
  • legacy account_id holding an external number;
  • account_ids winning over account_id;
  • an untargeted account matching nothing.
• TestGetUpcomingPurchases_ProviderAndAccountCombine.
• TestGetUpcomingPurchases_OutOfScopeAccount, for a session restricted to Production and GCP:
  • the baseline hides Staging;
  • account_ids=<Staging> gives an empty 200;
  • a mixed in-scope/out-of-scope selection keeps only the in-scope part;
  • an out-of-scope legacy external number matches nothing;
  • an in-scope legacy external number still matches.
• TestHandleRequest_DashboardUpcomingAppliesQueryFilters: through the router.

Fail-before, on main 7b86e38 with only the test file added:

$ go test ./internal/api/ -count=1 -run 'TestGetUpcomingPurchases_|TestHandleRequest_DashboardUpcomingAppliesQueryFilters' -v
--- PASS: TestGetUpcomingPurchases_NoFilterUnchanged
--- FAIL: TestGetUpcomingPurchases_ProviderFilter
--- FAIL: TestGetUpcomingPurchases_InvalidFilterIs400
    --- FAIL: .../unknown_provider
    --- FAIL: .../non-uuid_account_ids
--- FAIL: TestGetUpcomingPurchases_AccountFilter
--- FAIL: TestGetUpcomingPurchases_ProviderAndAccountCombine
--- FAIL: TestGetUpcomingPurchases_OutOfScopeAccount
--- FAIL: TestHandleRequest_DashboardUpcomingAppliesQueryFilters
FAIL	github.com/LeanerCloud/cloud-commitments-platform/internal/api

Pass-after, on this branch: all of them pass, along with the existing TestHandler_getUpcomingPurchases* and TestHandleRequest_DashboardUpcomingFlagsStepWithoutRecommendations.

Mutation probes, run locally and reverted:

• Dropping the provider-bucket external-id match in matchesAny fails TestGetUpcomingPurchases_OutOfScopeAccount.
• Dropping the unknown-provider ("") bucket match fails TestGetUpcomingPurchases_AccountFilter.

Other commands run on this branch, all clean (run with AWS_CONFIG_FILE=/dev/null AWS_SHARED_CREDENTIALS_FILE=/dev/null AWS_EC2_METADATA_DISABLED=true):

• go build ./...
• go vet ./...
• go vet -tags integration ./...
• go test ./internal/api/ -count=1: ok (48s)
• go test ./internal/mocks/ -count=1: ok
• golangci-lint run --allow-parallel-runners ./internal/api/ (v2.10.1): 0 issues
• gocyclo -over 10 -ignore "_test\.go" internal/api/handler_dashboard.go internal/api/handler_dashboard_upcoming_filter.go: no output

Combined-tree verification. This branch was tested together with the other queued branches on a local, never-pushed tree: queue/platform @ 400d256b = origin/main 7b86e386 plus these heads, merged in this order:

Branch	Tested head
fix/issue-243-rest	007c163
fix/issue-1206	312072f
fix/issue-111-email	6d422e2
fix/issue-111-fail-closed	3817e29
fix/issue-712-age-cap	a91120b
fix/issue-712-fargate	aeaf0d4
fix/issue-613-legacy-ids	350e837
fix/issue-120-guards	6f38ebc
fix/issue-120-shared-predicate	cb25735
fix/issue-151-account-update-keep	d20cf01
fix/issue-713-upcoming-filter	e73fdfb
fix/issue-263-bastion-opts	7861f32
fix/issue-43-fixture-ids	8cee203
fix/issue-177-makefile-walk	365a9d6
fix/issue-27-seller-not-registered	d845f66
fix/issue-313-user-columns	6d759dd
fix/issue-353-mock-panics	aac2edf
fix/issue-8-config-stamps	b548ae5
fix/issue-30-monthly-totals	f637921

Linux, Go 1.26.9, AWS_CONFIG_FILE=/dev/null AWS_SHARED_CREDENTIALS_FILE=/dev/null AWS_EC2_METADATA_DISABLED=true; Docker Postgres via testcontainers. The full suite ran on f7c48020, which differs from this tree only by test-only commits on fix/issue-30, fix/issue-713 and fix/issue-263 that replace placeholder account-number literals with named constants:

• Passed: go build ./..., go vet ./..., go vet -tags integration ./... and the full go test -race -short -count=1 ./....
• Static checks: golangci-lint v2.10.1 found 0 issues on every changed package, with and without --build-tags integration. gocyclo -over 10 is silent on the changed non-test files.
• Integration tests, every changed package that has them, one package at a time (-tags integration -count=1): internal/analytics, internal/api, internal/auth, internal/config, internal/database/postgres/migrations, internal/purchase, internal/scheduler and internal/server all pass. Migrations 000149, 000150 and 000151 apply in order on this tree.
• Frontend: the changed jest files (approval-details, settings-accounts, api) pass (221 tests).
• Secrets: the first run flagged 9 new fixture lines (placeholder account numbers next to an account key); fixed with named constants. Re-run on this tree: git-secrets, using the repo's scripts/setup-git-secrets.sh patterns in a fresh repo with an isolated HOME, found nothing in the changed files, and a planted fake key was flagged. scripts/test-git-secrets-allowlist.sh: 183 PASS, 0 FAIL.
• Terraform .tftest.hcl files were not run locally (CI runs them). Nothing was applied to any cloud.

Out of scope

• No frontend changes (the UI owner's area; see below).
• The response still carries no account field per row. It isn't needed now that the server filters.

Frontend follow-up for the UI owner

Once this lands, the widget can drop its client-side workaround from #1365:

1. frontend/src/api/dashboard.ts: give getUpcomingPurchases the same signature and query building as getDashboardSummary. That means provider plus account_ids (comma-joined), e.g. /dashboard/upcoming?provider=…&account_ids=…. An empty provider is accepted as "all".
2. frontend/src/dashboard.ts: pass state.getCurrentProvider() and state.getCurrentAccountIDs() at both call sites, the initial load (around line 167) and retryUpcomingPurchases (around line 501). The widget then refetches whenever Home reloads for a chip change.
3. Remove the UPCOMING_ACCOUNT_SCOPE_NOTE "The account filter does not apply here" note and its rendering in renderUpcomingPurchases. scopeUpcomingToProvider becomes redundant: it's harmless to keep, but it can go. Keep upcomingEmptyMessage, so an empty filtered result still names the provider. Update the lib/upcoming-scope.ts header comment, which says the endpoint takes no filter parameters.

Maintainer: please mirror the issue's triage labels on this PR: priority/p2, severity/high, urgency/this-quarter, impact/all-users, effort/s, type/bug, triaged.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 59 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: LeanerCloud/cloud-commitments-platform
• Branch: main
• File: .coderabbit.yaml
• Commit: 7b86e38
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 253db06c-2e43-49c1-9fa8-86bb629efb95

Commits

Reviewing files that changed from the base of the PR and between 7b86e38 and 7cc6e90.

Files ignored due to path filters: 1

• go.sum is excluded by !**/*.sum

Files selected for processing: 5

• go.mod
• internal/api/handler_dashboard.go
• internal/api/handler_dashboard_upcoming_filter.go
• internal/api/handler_dashboard_upcoming_filter_test.go
• internal/api/openapi.yaml

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{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): VERDICT: APPROVE 7cc6e903ad5894fdb09fc8be7573760469184689

Blocking:

• none

Non-blocking:

• internal/api/handler_dashboard_upcoming_filter.go matches: for a restricted session, isExecutionInScope has already called executionAccounts for the row. For a fan-out child (CloudAccountID set), the filter calls it again, and lookupCloudAccount isn't memoised, so each child row costs one extra cloud-account read when an account filter is set. This is harmless at today's row counts. If it matters, the in-scope check could return the accounts it already resolved.
• Account matching by external ID (matchesAny) means two cloud_accounts rows with the same external number under the same provider match each other's executions. That's the same dual-column behaviour as /api/dashboard/summary, so it's consistent, not new.
• The "any selected account matches a plan-level parent" rule means that with the chip on Production, the multi-account parent row still shows its full plan-level estimated_savings, including the Staging share. That's a reasonable choice and it's documented in openapi, but the UI owner should know the figure isn't pro-rated.

Attacked:

• Scope leak: the filter runs after isExecutionInScope, so it can only remove rows. For a restricted session a plan-level parent is visible only when every plan account is allowed, so the "any account matches" rule can't surface rows the session couldn't already see. The account selection goes through resolveDashboardAccountScope → intersectAccountFilterScope. I read both, including the ""-bucket re-grouping for a legacy external number. An out-of-scope id becomes an empty non-nil set, which matches nothing, never everything. I also checked that account_ids=",,," falls through to "no filter", same as the summary.
• Validation: providerFilterParam and parseAccountIDs run before any store read, the 200-id cap is inherited, and the openapi enum matches validProviders.
• Fail-before: I reset handler_dashboard.go to origin/main and removed handler_dashboard_upcoming_filter.go, keeping the new test file. All new tests except _NoFilterUnchanged FAIL (by design, that one passes both ways). I restored the files afterwards.
• Ran on e73fdfb6: go build ./...; go vet with and without -tags integration on internal/api; golangci-lint v2.10.1 with and without --build-tags integration (0 issues); gocyclo -over 10 on both changed non-test files (silent); go test -race -short -count=1 ./internal/api/ (ok); go test -race -tags integration -count=1 ./internal/api/ (ok, 781s, real Postgres).
• The head moved to 7cc6e903 while I was reviewing. The only new commit is the x/net v0.62.0 bump, byte-identical to fix(deps): bump golang.org/x/net to v0.62.0 (GO-2026-6860, GO-2026-6866) #1564. On 7cc6e903 I re-ran go build ./... and go vet ./..., both clean.

Body-stale:

• none

_{Reviewer: rG1. Bar while the maintainers are away (set by IAmJSD as acting owner): one approving independent review on the head, two for money, auth and security paths.}

[IAmJSD]

Local verification at 7cc6e903ad5894fdb09fc8be7573760469184689 merged onto main (d05a1726), together with #1547, #1555, #1558, #1559, #1561, #1562 in that order (combined tree eea0132d, Linux, Go 1.26.10): go build ./..., go vet with and without -tags integration, the full go test -race -short -count=1 ./..., and go test -race -tags integration -count=1 on every changed package, against Docker Postgres. All pass. CI Success and pre-commit are green on this head, with 1 approving independent review(s) on it. Nothing was run against any cloud.

[IAmJSD]

Merged by IAmJSD's agent at IAmJSD's request (IAmJSD is acting owner while the maintainers are away), under the bar IAmJSD set: 1 approving independent review(s) on 7cc6e903, green CI, and the combined-tree verification above. Squash-merged at exactly 7cc6e903ad5894fdb09fc8be7573760469184689.