feat: inject project_id as system dimension on valid events#60
Merged
Conversation
After central validation passes, decode the event's data payload and write project_id (extracted from ce.Subject()) into Dimensions before publishing to the valid NATS subject. Key changes: - Add internal/event import to consumer.go - Decode EventData post-validate(), initialise Dimensions map if nil, set Dimensions["project_id"] = project, re-encode before publish - Update happy-path and deprecated-meter tests to assert project_id is present in the published event's data dimensions The injection is deliberately post-validation so it bypasses the INVALID_DIMENSIONS check, which rejects emitter-supplied dimension keys not declared in MeterDefinition.spec.measurement.dimensions. project_id is a platform dimension that must not require per-meter declaration.
3 tasks
mattdjenkinson
requested review from
JoseSzycho,
kevwilliams,
savme and
scotwells
The test previously forced the PM to Active before creating the BillingAccount. The PM watch event fired while the account didn't yet exist, making it a no-op. When the account was then created and reconciled, the informer cache might still hold the stale (non-Active) PM — no further event would drive a re-reconcile, so the condition stayed False and the test timed out. Fix: create the BillingAccount first, then set the PM to Active. The watch event now fires while the account exists, enqueues a reconcile, and the controller observes the Active phase on that reconcile.
JoseSzycho
reviewed
Jun 17, 2026
scotwells
requested changes
Jun 17, 2026
Contributor
Author
|
@scotwells i'll change the dimension, no probs. I didn't add it explicitly as the project will always be present on a valid cloud event. Should i add a "SystemDimensions" field to the meterDefinitionStatus to make it explicit? |
Contributor
|
@mattdjenkinson yeah we need some way of surfacing the system dimensions, otherwise the provider (e.g. amberflo) won't know to configure them when setting up the meter. The status is good for that. |
Add SystemDimensionProjectName constant and SystemDimensions field to MeterDefinitionStatus so providers (e.g. amberflo-provider) can discover which dimensions the billing pipeline injects on every valid event and configure them in downstream metering systems alongside spec.measurement.dimensions. Key changes: - SystemDimensionProjectName constant in the API package; consumer and tests now reference the constant instead of the raw string - SystemDimensions []string on MeterDefinitionStatus, populated by the MeterDefinition controller on every reconcile - slicesEqual helper for the controller's change-detection early exit
Contributor
Author
|
@scotwells @JoseSzycho confirmed the changes based on your reviews work e2e. |
JoseSzycho
approved these changes
Jun 18, 2026
JoseSzycho
approved these changes
Jun 18, 2026
JoseSzycho
approved these changes
Jun 23, 2026
scotwells
approved these changes
Jun 24, 2026
scotwells
left a comment
scotwells
left a comment
Contributor
There was a problem hiding this comment.
I'd expect some chainsaw end to end tests for this
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
3 participants
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
Amberflo usage events today carry no project context as a queryable dimension. The project name is already present in the CloudEvent subject (
projects/{name}) and extracted by the consumer, but it is discarded after attribution. This means the cloud-portal has no way to ask Amberflo "show me usage for project X" — it can only filter by billing account, which loses per-project granularity when multiple projects share an account.This PR injects
project_idintoEventData.Dimensionsafter central validation passes, before the enriched event is published to the valid NATS subject. Because the injection happens post-validation, it bypasses theINVALID_DIMENSIONScheck — that check enforces emitter-supplied dimensions are declared in theMeterDefinition;project_idis a platform-level dimension that should not require per-meter declaration.The downstream amberflo-provider already forwards
data.Dimensionsto Amberflo (viasubmission.go), so this change is sufficient to makeproject_idappear on every measurement in Amberflo without changes to any emitting service.Test plan
TestUsageConsumer_HappyPath_PublishesToValid— assertsproject_id=proj-abcin published event dimensionsTestUsageConsumer_DeprecatedMeter_PassesValidation— assertsproject_id=proj-deprecatedin published event dimensionsgo test ./internal/controller/consumer/...project_iddimension