Send the Cloud Connector instance uid in self-managed billing events

Dmytro Biryukovrequested to merge
629740-billing-events-send-cloud-connector-instance-uid into master

What does this MR do and why?

On GitLab Self-Managed and GitLab Dedicated, Gitlab::BillingEvents::Client sends unique_instance_id as Gitlab::GlobalAnonymousId.instance_uuid, a UUIDv5 the instance derives for itself. CustomersDot resolves self-managed billing events only through the instance uid it issued to the instance in the Cloud Connector token (the gitlab_instance_uid claim). The two values never match, so every secrets_read event from a self-managed instance fails enrichment on CustomersDot with Source not found: trial credits are never consumed and paid usage is never billed.

This MR makes the EE override of the client send the token's gitlab_instance_uid claim as unique_instance_id on self-managed and Dedicated. GitLab.com keeps the current value. When no token is available, the claim is missing, or the token cannot be decoded, the client falls back to the previous value, and a decode failure is reported to error tracking without failing the event. event_id derivation is unchanged, so retries still produce the same id.

The same mismatch was fixed on the CustomersDot side for runner events in Bug: runner_compute_usage events unique_instance_id does not resolve to a subscription and, through the license, for the Duo quota check in Update Ai::UsageQuotaService to Send Cloud Connector Token gitlab_instance_uid as unique_instance_id.

Resolves https://gitlab.com/gitlab-org/gitlab/-/work_items/629740

Found during https://gitlab.com/gitlab-org/gitlab/-/work_items/628023

References

  • lib/gitlab/billing_events/client.rb: unique_instance_id extracted into a private method so EE can override it.
  • ee/lib/ee/gitlab/billing_events/client.rb: the override reading the Cloud Connector token claim, with fallback.
  • ee/spec/lib/ee/gitlab/billing_events/client_spec.rb: claim sent on self-managed, stable event_id, every fallback path, error report on a bad token, GitLab.com never reads the token.
  • doc/development/internal_analytics/internal_event_instrumentation/billing_events_tracking.md: describes both instance identifiers.

How to set up and validate locally

  1. On a self-managed instance activated against CustomersDot (staging works), enable the billing_event_tracking feature flag.

  2. Read a Secrets Manager secret from a CI job.

  3. In the Rails log, find BillingEvents: billing event tracked and check the unique_instance_id in the billable usage context equals the gitlab_instance_uid claim of the instance's Cloud Connector token:

    JWT.decode(CloudConnector::ServiceAccessToken.active.last.token, nil, false).first['gitlab_instance_uid']

  4. On CustomersDot, the event now appears in usage_billing_enriched after the hourly enrichment job instead of in enrichment_failures.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

🤖 Generated with Claude Code

Merge request reports