Gate Siphon-dependent analytics engines on replication

What does this MR do and why?

Gates the five Siphon-dependent analytics aggregation engines (duoWorkflows, pipelines, contributions, deployments, mergeRequests) behind a check that Siphon replication is enabled on the instance. These engines had no data-source gate at all before this MR: just returning an error in case ClickHouse is down. On an instance where Siphon has never replicated, they silently return zeros instead of signaling that the data source is absent. Gitlab::ClickHouse.siphon_enabled? also returns false when ClickHouse itself is not configured, so this one check covers both cases. Adds a small Analytics::RequiresSiphonReplication concern, included into each of the five mount_aggregation_engine blocks in AnalyticsType, that raises a resource-not-available error via Gitlab::ClickHouse.siphon_enabled? before falling through to the engine's own ready?. The three engines that don't depend on Siphon (agentPlatformSessions, duoCodeSuggestions, duoUsageEvents) are unaffected.

The five gated field descriptions now note the Siphon requirement, and the GraphQL reference docs / introspection schemas are regenerated accordingly.

References

Implements https://gitlab.com/gitlab-org/gitlab/-/work_items/629147

Screenshots or screen recordings

N/A - backend-only GraphQL change, no UI.

How to set up and validate locally

  1. Enable ClickHouse for analytics but leave Siphon unconfigured/not replicating.
  2. Query any of analytics.duoWorkflows, analytics.pipelines, analytics.contributions, analytics.deployments, or analytics.mergeRequests on a group or project.
  3. Confirm the response returns a "Siphon replication is not enabled on this instance." error instead of empty aggregated data.
  4. Confirm analytics.agentPlatformSessions, analytics.duoCodeSuggestions, and analytics.duoUsageEvents still resolve normally.

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.

Edited by Serhii Yarynovskyi

Merge request reports

Loading
Loading