[HTExplicit]

Problem

GET /admin/accounts/upstream-billing-rates returns the billing-rate snapshots of "the current account-list page". The account page applies them in place only when the returned total and account ID order equal the list's; otherwise it reloads the whole list.

The endpoint is still upstream's code, and this fork's list has moved on:

• the list reads its group filter as group_id, the endpoint read group;
• the list has multi-value console filters (platforms, types, statuses, plans, proxies, folder, tags, account_ids) served by the console service, the endpoint only knew the single-value ones;
• the page built the endpoint's filters from params.platform/type/status/group, keys it no longer sets.

So with any of those filters active the endpoint answered for a wider set, and the refresh that follows a billing probe always fell back to a full list reload.

Correction to how this was first reported (to the owner and in the workspace notes): it was described as a reload "every 5 minutes". That is wrong. The page's 5-minute timer, useIntervalFn(..., { immediate: false }) with the return value discarded, is never started by @vueuse 10.11 — the same line is in upstream. The only live caller is the refresh after a billing probe. This PR does not change the timer.

Change

• Backend. GetUpstreamBillingRates resolves accounts the way List does for the same query: group from group_id (same accepted values and the same INVALID_GROUP_FILTER 400), the older group only when group_id is absent, and the console service when hasAccountConsoleFilters is true. Response shape, ETag and Cache-Control are unchanged. List is not modified.
• Frontend. The rates request carries the list request's filter parameters (buildConsoleAPIParams(true), including the resolved search, so a key search sends the digest term). The legacy keys are no longer sent. No UI change.
• Console ordering. accountConsoleQuery now breaks ties by account ID, as the plain list ordering already does. Without it one query could return tied rows in different orders, so console pages could overlap and the rates request could disagree with the list on order.

Verification

• Backend: gofmt, go build ./..., go vet (handler package; repository package with the integration tag), and the new handler tests together with the existing List tests.
  • Parity test: the same query string goes to List and to the rates endpoint on one router, and the recorded service call must be equal (13 queries, both paths); invalid filters fail alike on both; the older group name; response shape, ETag and 304 for a console-filtered request.
  • Mutation checks: skipping the console branch, reading only group, and the unmodified handler each fail these tests.
• Frontend: vue-tsc --noEmit, eslint on the touched files, and the three specs that reach this request (44 tests). New cases: the request carries the list request's filters at the current page; a matching answer is applied in place without a list request; a key search sends the digest term. Restoring the old filter builder fails the first case.
• One review pass over parity/behaviour and over tests/CI, each finding checked by a second reader: no confirmed defect. Its one observation, the missing tie-break, is fixed here.

Not run locally: the new integration case TestAccountTaxonomyConsoleOrderBreaksTiesByIDIntegration needs Docker and runs in CI. No full suites, no real model calls.

🤖 Generated with Claude Code