Block Orbit queries when no billing namespace can be resolved

Sharmad Nachnolkarrequested to merge
snachnolkar/622338-orbit-governing-namespace-alert into master

What does this MR do?

On GitLab.com, Orbit usage is attributed to a billing namespace that users select in their preferences. When no billing namespace can be resolved, the user's usage cannot be attributed, so their Orbit queries are blocked.

Until now the Rails pre-check (GoverningNamespaceGuard) blocked only users with two or more eligible namespaces. Users with no eligible namespace were let through, and the missing billing namespace was only caught later. This MR makes the guard block every user whose billing namespace cannot be resolved (none, or several with no selection). It returns the same billing_namespace_required error, with an empty candidates list when there are none. Because the guard now uses the same lookup as the JWT root_namespace_id claim, the two stay in sync.

The dashboard alert for users with several eligible namespaces already exists on master and is unchanged. Everything is behind the knowledge_graph_billing feature flag (default disabled).

Related to https://gitlab.com/gitlab-org/gitlab/-/issues/622338

Related work

  • !255042 (merged) (merged) added the Rails pre-check and the shared error contract.
  • !260940 (merged) (merged) made promo and trial namespaces count as candidates. Enable orbit_promo_access_gate before knowledge_graph_billing, so users with promo or trial access are not blocked.

How to set up and validate locally

  1. Enable the feature flag and simulate SaaS locally, so Gitlab::Saas.feature_available?(:gitlab_com_subscriptions) returns true:

    Feature.enable(:knowledge_graph_billing, User.find_by_username('root'))

  2. As a user with no billing namespace candidate and no saved preference (for example, banned from the only Ultimate group but a member of a Free group with knowledge graph enabled), send POST /api/v4/orbit/query. Expect 422 with code: billing_namespace_required and candidates: []. /api/v4/orbit/mcp returns the same data in a JSON-RPC error.

  3. As a user with two eligible groups and no preference, expect 422 with both groups listed in candidates.

  4. As a user with one eligible group, or a saved preference, the guard does not block the request.

Edited by Sharmad Nachnolkar

Merge request reports