Resolve the Orbit access state for 10 groups and check the admin turn on

What does this MR do and why?

orbitAccess now resolves for up to 10 groups in one request, so the Orbit dashboard can read the turn-on state of each group from the server. The admin API that turns on Orbit for a namespace now follows the same turn-on rules as an Owner.

  • One CustomersDot outage now costs one timeout and one Sentry event for the whole request, for orbitAccess and orbitTrial together.
  • The admin API returns 403, 503, or 400 where it returned 200 before: when the group needs a trial, when CustomersDot does not answer, or when the group is excluded from indexing. A CustomersDot client error also gives 503, because the turn-on service already treats every CustomersDot error as unavailable.

Closes https://gitlab.com/gitlab-org/orbit/knowledge-graph/-/work_items/1380

References

Screenshots or screen recordings

No UI change.

How to set up and validate locally

  1. As an Owner of several top-level groups, run this query in GraphiQL. Expect one orbitAccess for each group, and no error:

    {
      groups(topLevelOnly: true, ownedOnly: true, first: 10) {
        nodes { fullPath orbitAccess { state turnOnDenialReason } }
      }
    }
  2. In GitLab.com mode, turn on the orbit_promo_access_gate flag for a group without the add-on or a trial. As an administrator with admin mode on, call the admin API. Expect 403 "Start a free trial to turn on Orbit for this group.":

    curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" \
      --url "http://127.0.0.1:3000/api/v4/admin/knowledge_graph/namespaces/<group_id>"

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 Jean-Gabriel Doyon

Merge request reports

Loading
Loading