## The Why <details><summary>Expand to read The Why</summary> In GitLab 18.5 we built a PostgreSQL-based data source for a GitLab Duo usage dashboard, aimed at self-managed customers without ClickHouse. It aggregated AI usage events into daily counts every 5 minutes and exposed code suggestion shown/accepted counts through an experimental GraphQL field on groups and projects. See issue https://gitlab.com/gitlab-org/gitlab/-/issues/558280, and merge requests https://gitlab.com/gitlab-org/gitlab/-/merge_requests/205716 and https://gitlab.com/gitlab-org/gitlab/-/merge_requests/207721. The parent epic https://gitlab.com/groups/gitlab-org/-/epics/19630 was closed on 2026-02-12. The product manager's closing note states the team will not pursue a PostgreSQL-based Duo dashboard, and will instead focus on the ClickHouse dashboard and APIs, with ClickHouse expected to become generally available across all deployment tiers. PostgreSQL-only installs will get raw data via API instead. The planned frontend consumer, https://gitlab.com/gitlab-org/gitlab/-/issues/578196, was closed with no merge request. Today nothing consumes this field: no frontend code and no other internal project queries it. Keeping it costs us a cron job running every 5 minutes on every instance, writing data nobody reads; a growing partitioned table that keeps getting pruned; dead code that reviewers and the Optimize group must keep maintaining; and an experimental public API surface that could be mistaken for something supported. The field is marked experimental, so it can be removed at any time without a deprecation cycle. </details> ## Proposal Remove the background aggregation job, the experimental GraphQL field, and the underlying storage table. There is no user-facing feature change: the ClickHouse-backed AI metrics that customers actually use today remain untouched. The removal happens in two phases across consecutive milestones, because the table can only be dropped once no running code references it, and the worker class must outlive its purged jobs by one release. It should save us some CPU cycles, roughly 1.5Gb in DB space and reduce codebase size. --- ## Technical Proposal Today a Sidekiq cron worker aggregates AI usage events into a dedicated table every 5 minutes, and an experimental GraphQL field reads that table to serve code suggestion metrics on groups and projects. This work removes the worker's behavior and all the application code first, then drops the table and the worker class itself one milestone later. One GraphQL type in the ClickHouse-backed metrics path currently inherits two fields from the type being removed, so those two fields need to be inlined rather than deleted. ## Implementation details **Phase 1 (milestone M): remove the model and application code, neutralize and unschedule the worker, purge queued jobs.** - Remove the `analytics_refresh_ai_events_counts_cron_worker` entry from `ee/config/schedule.yml` and from the cron key list in `ee/spec/initializers/1_settings_spec.rb`. - Replace the `perform` body of `ee/app/workers/analytics/ai_analytics/events_count_aggregation_worker.rb` with a no-op. Keep the class itself, its `idempotent!`, `deduplicate :until_executed`, `data_consistency :sticky`, its feature category, and its `all_queues.yml` entry. Update the worker spec to assert the no-op. - Remove the worker call from `ee/db/fixtures/development/94_ai_usage_stats.rb`. - Delete `ee/app/services/analytics/ai_analytics/usage_events_counter_service.rb`, `ee/app/services/analytics/ai_analytics/postgresql/code_suggestion_usage_service.rb`, both resolvers and both types under `ee/app/graphql/.../analytics/ai_metrics_basic/`, the `ai_metrics_basic` field in `ee/app/graphql/ee/types/group_type.rb` and `ee/app/graphql/ee/types/project_type.rb`, the `Ai::EventsCount` model (`ee/app/models/ai/events_count.rb`), its factory `ee/spec/factories/ai/events_counts.rb`, and the related specs (`ee/spec/models/ai/events_count_spec.rb`, `ee/spec/services/analytics/ai_analytics/usage_events_counter_service_spec.rb`, `ee/spec/services/analytics/ai_analytics/postgresql/code_suggestion_usage_service_spec.rb`, `ee/spec/workers/analytics/ai_analytics/events_count_aggregation_worker_spec.rb`, `ee/spec/requests/api/graphql/analytics/ai_analytics/ai_metrics_basic_spec.rb`). - Inline the `accepted_count` and `shown_count` fields directly into `ee/app/graphql/types/analytics/ai_metrics/code_suggestion_metrics_type.rb` (it currently inherits them from the type being deleted); a rubocop `GraphQL/ExtractType` disable will be needed. The public `codeSuggestionMetrics` type must keep returning `acceptedCount` and `shownCount`. - Remove `Ai::EventsCount` from `config/initializers/postgres_partitioning.rb` and from `spec/services/organizations/transfer/users_service_spec.rb`. Remove the `type:AiMetricsBasic` and `type:codeSuggestionMetricsBasic` lines from `config/authz/graphql/authorization_todo.txt`. Regenerate `doc/api/graphql/reference/_index.md` with `bundle exec rake gitlab:graphql:compile_docs` and `public/-/graphql/introspection_result.json` with `bundle exec rake gitlab:graphql:generate_introspection_schema`. - Add a regular migration (`db/migrate`, not post-deploy, `disable_ddl_transaction!`) that, inside `Gitlab::SidekiqSharding::Validator.allow_unrouted_sidekiq_calls`, destroys the `analytics_refresh_ai_events_counts_cron_worker` cron entry and calls `sidekiq_remove_jobs` for `Analytics::AiAnalytics::EventsCountAggregationWorker`, with a no-op `down`. - Note: GitLab's Sidekiq removal guidance normally puts the no-op change and the job-purging migration in separate releases, because a node still running old code during a rolling deploy could enqueue a new job after the migration ran. Here both land in the same release because the worker is already a no-op, so any such straggler job is harmless and finishes instantly. - Keep the no-op worker class and its `all_queues.yml` entry; those are removed in phase 2. Optionally clear the Redis cursor key `ai_events_counts_cursor`. No GraphQL deprecation is needed since the field is experimental. **Phase 2 (milestone M+1): drop the table and finish worker removal.** - Delete the worker class file `ee/app/workers/analytics/ai_analytics/events_count_aggregation_worker.rb`, its spec, and its `all_queues.yml` entry. - Add a post-deployment migration using `Gitlab::Database::PartitioningMigrationHelpers` and `disable_ddl_transaction!`. In `up`, remove the foreign key to `organizations` with lock retries, then drop the `ai_events_counts` table with `force: :cascade` (required because the dynamic monthly partitions depend on the table's id sequence, and a plain drop fails with a dependent-objects error). There is precedent for this pattern in `db/post_migrate/20260702122700_drop_ai_code_suggestion_events_table.rb`. - `down` recreates the partitioned table (range-partitioned by `events_date`, with `id`, `events_date`, `namespace_id`, `user_id`, `organization_id`, `event`, and `total_occurrences` columns), its unique and lookup indexes, its id sequence, and its foreign key via the partitioned-foreign-key helper. - Move `db/docs/ai_events_counts.yml` to `db/docs/deleted_tables/ai_events_counts.yml`, clear its `classes`, and add `removed_by_url` and `removed_in_milestone`. - Remove the `ai_events_counts: supported` line from `config/organizations/transfer_support.yml` and the `ai_events_counts` entry from `spec/db/schema_spec.rb`. - Regenerate `db/structure.sql` with `scripts/regenerate-schema` rather than from a local dev database, to avoid unrelated drift in the diff. ## Acceptance criteria - [ ] After phase 1, there is no cron entry and no scheduled Sidekiq jobs for the aggregation worker on GitLab.com. - [ ] After phase 1, `aiMetricsBasic` is absent from the GraphQL schema and from the generated GraphQL reference docs. - [ ] After phase 1, `codeSuggestionMetrics` still returns `acceptedCount` and `shownCount` from the ClickHouse-backed path. - [ ] After phase 2, the `ai_events_counts` table is absent from `db/structure.sql` and its dictionary entry is present under `db/docs/deleted_tables`. - [ ] After phase 2, no references to the removed worker, services, resolvers, types, model, or table remain anywhere in the repository. ## Out of scope - The raw `ai_usage_events` table and the `Ai::UsageEvent` model, which are still used by other features such as per-user AI metrics. - The ClickHouse-backed `aiMetrics` field and its dashboards. - Any change to how PostgreSQL-only instances obtain Duo usage data going forward.