Draft: WIP: Introduce eligible_for_a_seat for Gitlab.com
What does this MR do and why?
This MR aims to address the solutions outlined in https://gitlab.com/gitlab-org/gitlab/-/work_items/443497#note_1792855852.
Changes:
- Introduces
eligible_for_a_seat
for Gitlab.com. - Reduces queries by early evaluation of
gitlab_duo_pro_eligible_user_ids
.
Findings:
- The
gitlab_duo_pro_eligible_user_ids
method does not significantly improve query performance. - Many queries are still fired for less than 50 users.
- Numerous checks and queries are executed for individual user records.
- Query volume increases with depth (e.g., subgroup and project membership checks).
- It's unclear how to reduce query volume without exploring solutions at the membership hierarchy level.
- Suggestions for optimization are welcome, considering the GraphQL API's maximum of 100 queries per request.
- It's uncertain if the GraphQL API is a viable solution or if REST should be considered.
- The spike (!143342 (diffs)) involved direct upserting of
user_ids
, which does not validate anything. - The preferred solution should focus on optimizing the current create service.
Related to #442284