### Summary GraphQL analytics `aggregated` queries return HTTP 500 ("Internal server error") when a `date_bucket` dimension is requested with a fixed-day granularity (e.g. `30d`) together with the `origin` argument, on a Nullable ClickHouse column. The same query without `origin` works. On non-null columns, `origin` works fine and buckets are anchored correctly. ### Steps to reproduce Run this query against `gitlab-org/glql` on gitlab.com: ```graphql query { project(fullPath: "gitlab-org/glql") { analytics { pipelines { aggregated(first: 3) { nodes { dimensions { startedAt(granularity: "30d", origin: "2026-07-18T00:00:00Z") } totalCount } } } } } } ``` Response: ```json {"errors":[{"message":"Internal server error"}]} ``` Control query (works), same dimension without `origin`: ```graphql startedAt(granularity: "30d") ``` This returns buckets, including a `null` bucket. The error also happens with a filter that excludes nulls entirely, e.g. `pipelines(status: ["success"])`, where `started_at` is never null. So the failure is tied to the column's type (Nullable), not to actual null values in the result set. Confirmed on gitlab.com on 2026-09-16 and 2026-09-17 by @drosse, and again on 2026-09-17 by @pshutsin. | Dimension | Column nullability | `origin` + fixed-day granularity | |---|---|---| | pipelines `startedAt` | Nullable | fails (500) | | pipelines `finishedAt` | Nullable | fails (500) | | merge requests `metricMergedAt` | Nullable | fails (500) | | sessions `createdEventAt` | Nullable | fails (500) | | merge requests `createdAt` | non-null | works | | code suggestions `timestamp` | non-null | works | | duoWorkflows `createdAt` | non-null | works | | contributions `createdAt` | non-null | works | ### What is the current *bug* behavior? Requesting a fixed-day granularity (e.g. `30d`) with `origin` on a Nullable date/time column causes the query to fail with a generic 500, instead of returning bucketed results. ### What is the expected *correct* behavior? The query should return bucketed results anchored at the given `origin`, with a `null` bucket for rows where the column value is null, the same way it does today when `origin` is omitted. ### Root cause Verified locally against ClickHouse 25.11.2.24. `Gitlab::Database::Aggregation::ClickHouse::DateBucketDimension#origin_literal` in `lib/gitlab/database/aggregation/click_house/date_bucket_dimension.rb` shifts the user-supplied origin back to a phase-equivalent anchor near the unix epoch: ```ruby Time.at(origin.to_i % days.days.to_i) ``` This always produces an anchor in `[1970-01-01, 1970-01-01 + N days)`. ClickHouse's 3-argument `toStartOfInterval(value, INTERVAL N DAY, origin)` uses the default Nullable implementation: the function is evaluated on the inner non-null column, where NULL positions hold the type default `1970-01-01 00:00:00`. That default is before the computed anchor, so ClickHouse raises: ``` Code: 36. DB::Exception: The origin must be before the end date / date with time (BAD_ARGUMENTS) ``` Because this is evaluated at the block/column level rather than per row, having any Nullable column triggers the check even when the actually filtered rows are all non-null. Local SQL repro: ```sql SELECT toStartOfInterval( arrayJoin([toNullable(toDateTime64('2026-08-01 10:00:00', 6, 'UTC')), NULL]), INTERVAL 30 DAY, toDateTime64('1970-01-09 00:00:00', 6, 'UTC') ) -- Code: 36. DB::Exception: The origin must be before the end date / date with time. (BAD_ARGUMENTS) ``` ### Possible fixes Verified fix direction: shift the anchor one full period earlier so it is strictly before the epoch, e.g. `1969-12-10 00:00:00` for a 30-day period currently anchored at `1970-01-09`: ```ruby anchor = Time.at(origin.to_i % days.days.to_i - days.days.to_i).utc ``` This produces the identical bucket (`2026-07-14 00:00:00`) for real values and returns NULL for NULL rows, with no error. DateTime64 supports dates back to 1900, and the maximum granularity is 399 days, so the anchor never goes below 1968-11-28. Alternative: wrap the column so NULLs are handled explicitly instead of relying on the default Nullable behavior of `toStartOfInterval`. The anchor shift above is the smaller change. Whichever fix is chosen, add a spec covering a Nullable date column combined with `origin`. ### Related - Discovered in https://gitlab.com/gitlab-org/glql/-/work_items/187#note_3851720685 (point 6) - Feature issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/609138 - Feature MRs: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254135 and https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254973 (GitLab 19.5) - Blocks using `origin` from GLQL for pipelines and merge-request merged-at based dashboards in the DAP Impact Dashboard