feat: filter Amberflo usage queries by project_id dimension#1317
Closed
mattdjenkinson wants to merge 1 commit into
Closed
feat: filter Amberflo usage queries by project_id dimension#1317mattdjenkinson wants to merge 1 commit into
mattdjenkinson wants to merge 1 commit into
Conversation
When a project is selected, include a dimensions filter on the Amberflo
/usage/sparse request so results are scoped to events emitted for that
specific project, not the entire billing account.
Key changes:
- Add optional projectId param to fetchUsageForCustomerIds
- Spread dimensions: { project_id: [projectId] } into the Amberflo
filter when projectId is set; no-ops when absent (org-wide queries)
- Thread projectId through fetchProjectUsage to the shared fetch helper
Requires the billing consumer to inject project_id as a system dimension
after event validation passes (see infra/docs/project-id-dimension-billing-change.md).
🧪 Test Summary
📎 ArtifactsVideos and screenshots from failed E2E tests:
|
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Usage queries sent to Amberflo are currently scoped only by
customerId(the billing account UID). When multiple projects share a billing account, or when the per-project billing account binding is absent, there is no way to isolate a single project's consumption in the response. This PR addsproject_idas an optional dimension filter on all Amberflo/usage/sparserequests so the portal can scope results to a specific project once events carry that dimension.The change is additive and backwards compatible: when
projectIdis undefined (org-wide views), the filter object is unchanged. When set,dimensions: { project_id: [projectId] }is spread into the existingcustomerIdfilter.Key behaviors:
fetchUsageForCustomerIdsaccepts an optionalprojectIdthat is forwarded as an Amberflo dimension filterfetchProjectUsagethreads theprojectIdit already resolves through to the shared fetch helperfetchOrgUsage) are unaffected — no dimension filter when no project is selectedTest plan
project_idon eventsprojectId→ no dimension filter in request body)no-billing-accountempty state still renders when no binding exists for the projectNotes for reviewers
This PR is intentionally a no-op until milo-os/billing#60 ships the consumer-side injection of
project_idas a system dimension. Until that lands, the dimension filter is sent to Amberflo but matches nothing, so results are unchanged from today.Confirm the Amberflo
/usage/sparsefilter format acceptsdimensions: { key: string[] }— if the API expects a different shape (e.g.dimensionFilters: [{ key, values }]), only the spread inqueryUsageneeds updating.