GitLab Credits dashboard fails silently when a date range preset predates the subscription start

Problem

On the GitLab Credits dashboard, selecting some date range presets makes the dashboard fail to show any data. There is a generic error message and no explanation, so the page just looks broken.

This affects customers whose subscription started recently, for example after a subscription change or renewal. Those users cannot query periods that predate their current subscription, and the presets that cover those periods are still offered in the filter even though they can never work.

This was noted during a Request For Help investigation.

Root cause

The GraphQL resolver at ee/app/graphql/resolvers/gitlab_subscriptions/subscription_usage_resolver.rb clamps the requested start_date up to the subscription start date when the subscription started more recently (clamp_start_date, around line 98-109). It does not clamp the end_date.

For a subscription that started on 2026-08-03, selecting "Last month" sends startDate: "2026-07-01" and endDate: "2026-07-31". The resolver rewrites that to startDate: "2026-08-03", endDate: "2026-07-31". The start date is now after the end date, so the resolver's own validate_date_range! check raises end_date must be after or equal to start_date. The frontend does not expect that error, so nothing useful is shown to the user.

Proposal

Fix this on the UI side by making the subscription start date available to the dashboard and using it to filter the date range options.

  • Pass the subscription start date from the view layer into the Vue app. For groups this comes from the group's gitlab_subscription.start_date; for self-managed instances it comes from License.billable_license&.starts_at. Both mirror what the resolver clamps against.
  • Drop presets whose end date falls entirely before the subscription started, since they can only ever produce an empty or invalid range.
  • Clamp presets that merely begin before the subscription start date, so they return real data instead of erroring.
  • Restrict the custom date picker so a user cannot pick a start date earlier than the subscription start.
  • Always keep the "Custom" option available. If the subscription start date is later than every preset, removing "Custom" too would leave the picker with no valid selection at all.
  • When no subscription start date is available, keep the current behavior: all presets are offered and the picker is unrestricted.

This is the follow-up that was named in https://gitlab.com/gitlab-org/gitlab/-/issues/596646, which deliberately deferred the UI-side restriction for 19.0. That issue said "Do not block or restrict the date range picker on the UI based on subscription start in 19.0" and "Filtering out impossible options from the UI picker can be a follow-up once subscription start is reliably available on the frontend."

Out of scope

What the API should do in this situation is still an open question. In https://gitlab.com/gitlab-com/request-for-help/-/work_items/5205#note_3698880233, Kos Palchyk (@kpalchyk) noted that "On the UI we definitely should hide impossible options", and listed three possible API-side options:

  1. Clamp the end date as well, so 2026-07-01 - 2026-07-31 becomes 2026-08-03 - 2026-08-03.
  2. Error out explicitly if the starting date is out of bounds. He was hesitant about this one, because the frontend does not expect such an error.
  3. Allow requesting out-of-range periods and return nullish or zero usage.

None of these are addressed here. Hiding the impossible options on the UI removes the user-visible breakage, but the resolver can still produce an inverted range if a request is made directly.

There is also a parity gap. The sibling app at ee/app/assets/javascripts/usage_quotas/user_credits_dashboard/index/components/app.vue reuses the same DateRangeFilter component and has the same problem. The new prop is optional, so that app keeps working as before, but it does not yet receive a subscription start date. That is worth a follow-up.

References

Edited by Sheldon Led