<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=630162) </details> <!--IssueSummary end--> ## Summary `dimensionValue()` in `app/assets/javascripts/glql/utils/chart_data.js` returns the display label of an object-typed dimension (`UserCore`, `Project`, `Group`) and that string doubles as the series identity in `buildSeries`, `buildBarSeriesData`, `buildStackedByDimension` and `buildStackedByMetric`. Rows that resolve to the same label overwrite each other instead of staying distinct: `valuesBySecondary.get(label)[i] = node[metric.key]` keeps the last value, so counts of 12 and 7 render as 7. Reachable with ordinary data since GLQL 0.39 (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256724): the `group` dimension returns one `null` row per project namespace at the requested depth, and every one of those rows collapses into the single `Unknown` category. Two users or two top-level groups with the same name collide the same way. ## Steps to reproduce ```yaml display: columnChart mode: analytics query: type = DuoWorkflow and group = "<group with flows in several projects>" and created > -30d dimensions: created(weekly), group(depth=2) metrics: totalCount ``` Compare the chart values with the same query as a `table`: the table lists every null-group row, the chart shows only the last one per bucket. ## Root cause on the backend The `group(depth:)` dimension is the generic ClickHouse aggregation dimension `traversal_path`, in `lib/gitlab/database/aggregation/click_house/traversal_path_dimension.rb`. It buckets by `nullIf(toUInt64OrNull(arrayElement(splitByChar('/', traversal_path), depth + 1)), 0)` - the id found at that depth of the row's traversal path, whatever kind of namespace it is. Both Duo engines (`ee/app/models/analytics/aggregation_engines/duo_workflows.rb` and `ai_usage_events.rb`) store project-scoped rows with the project namespace appended to the path, e.g. `1/24/25/` where 25 is a project namespace under group 24. So at `depth=2` every project namespace is its own GROUP BY bucket in ClickHouse - a real UInt64 id, one row per project. The GraphQL layer then resolves that id with `Group.id_in(ids)` (`app/graphql/types/analytics/aggregation/base_response_type.rb`), which is scoped to `type = 'Group'`, so every project namespace id resolves to `null`. Result: N distinct rows, all `group: null`, indistinguishable on the client. The dimension's own description already documents this: "Flows tracked in a project at that depth bucket by project namespace ID, which also resolves to NULL." Paths shorter than the depth already collapse into one SQL NULL row and get aggregated correctly in ClickHouse - this issue is specifically about ids that exist but resolve to the wrong type. The response never exposes the raw id either: `engine_response_dimensions_type.rb` declares association dimensions only as the resolved object, never as a scalar `groupId`. So the client has no way to re-group the null rows, and any client-side merge would be wrong for non-additive metrics (unique user counts, averages, quantiles). There's a second, smaller source of `null` rows: groups the viewer can't `read_group` also resolve to `null`, one row each. SQL can't fix that one, but it's rare in practice because analytics permissions are inherited down the group tree. ## Proposal Backend, this is the real fix and should happen first: - In `TraversalPathDimension#to_inner_arel`, map an id that isn't a group to NULL before the GROUP BY, so all project-namespace rows fold into the single NULL bucket and ClickHouse aggregates every metric correctly, unique counts included. ClickHouse already has `project_namespace_traversal_paths_dict` (and `siphon_namespaces` with a type column), so a `dictHas` against the project-namespace dictionary, or something equivalent, can classify the id. Need to check the query cost of that extra lookup at production data volumes - nothing in `lib/gitlab/database/aggregation` uses dictionaries yet. - Once that's in, the chart shows one "Unknown" bucket per period with the right numbers, and the table shows one row instead of N. Frontend, hardening, much lower priority once the backend collapses the rows: - Still worth separating identity from label: key series by the record `id` and format the label at the axis/legend edge, so two users sharing a display name stay distinct (usernames are unique, display names aren't). Project and group full names are practically unique, so this matters mostly for users. - Tables already pair rows by `identityOf` in `components/presenters/utils/table.js` - the chart path should share that helper instead of reimplementing it. - Don't number unresolved rows ("Unknown", "Unknown (2)") in charts. Series read as identities, and the numbers would fabricate identities that don't line up across buckets. The residual per-viewer null rows can stay a documented limitation. - There's a draft with the identity split already: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256969. It currently also numbers unresolved rows, which should be dropped, or the MR trimmed down to just the identity split. Related to https://gitlab.com/gitlab-org/glql/-/work_items/229