## Summary When a `Ci::Minutes::NamespaceMonthlyUsage` record does not exist for the current month (e.g., no CI jobs have run yet), the projects table in the pipelines quota tab (`data-testid="pipelines-quota-tab-project-name"`) is not populated. This is a regression introduced by the removal of the `aggregate_ci_minutes_reads` feature flag. ## Root Cause The projects table is populated through the following chain: 1. The frontend `app.vue` component fires the `getProjectsCiMinutesUsage` GraphQL query, which calls `ciMinutesUsage` with a `namespaceId` and `date`. 2. The **GraphQL resolver** `ci_minutes_usage` in `ee/app/graphql/ee/types/query_type.rb` fetches `NamespaceMonthlyUsage` records via `NamespaceMonthlyUsage.for_namespace(root_namespace)` or `.by_namespace_and_date(root_namespace, date)`. 3. Each returned `NamespaceMonthlyUsage` record becomes the `object` in `NamespaceMonthlyUsageType`. 4. The `projects` field on `NamespaceMonthlyUsageType` resolves by calling `ProjectMonthlyUsage.for_namespace_monthly_usage(object)`, which uses `object.namespace` and `object.date` to find matching project usage records. 5. The frontend `app.vue` computed property `selectedMonthProjectData` finds the matching month node from the response, then extracts `projects.nodes`. If no matching month is found, it returns `{}`, and `projects` falls back to `[]` — resulting in an empty table. The issue is that the `projects` field resolution is **nested inside** the `NamespaceMonthlyUsage` GraphQL type. If no `NamespaceMonthlyUsage` record exists for the current month, the GraphQL query returns **no nodes at all**, meaning the `projects` resolver is never invoked. Previously, with the `aggregate_ci_minutes_reads` feature flag disabled, the old code path used `find_or_create_current` which **lazily created** a `NamespaceMonthlyUsage` record on read, guaranteeing a record always existed. The new code path (`all_current_usages`) is read-only and returns nothing when no record exists. ## Proposed Solution(s) Decouple the project monthly usages from the namespace monthly usages by fetching them separately rather than relying on `ProjectMonthlyUsage` being nested under `NamespaceMonthlyUsage` in the GraphQL schema. This could be done by either: - Performing **two separate GraphQL queries**: one for namespace-level usage and one for project-level usage independently. - Performing **one query** that fetches both namespace and project monthly usages as **separate top-level fields**, rather than nesting projects under the namespace usage type. Either approach ensures that project usage data can be displayed even when no namespace-level usage record exists for the selected month. ## Related - Feature flag removal MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/229428 - Feature flag rollout issue: https://gitlab.com/gitlab-org/gitlab/-/issues/592211 - Original sharded CI minutes tracking issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/490968