## Summary When a merge request has more than 100 reviewers (which is permitted by the backend limit of 200), the MR sidebar reviewer widget only loads the first 100 reviewers due to the schema-wide GraphQL `default_max_page_size` of 100. When a user subsequently makes **any** edit through that sidebar widget (e.g. adding a single reviewer), GitLab silently reconciles the MR's full reviewer set to only what the widget holds in memory — permanently removing every reviewer beyond the first 100 **with no warning or indication to the user**. The same mechanism applies to the assignee widget via `get_mr_assignees.query.graphql`. ## Steps to Reproduce 1. Add more than 100 reviewers to a merge request (e.g. via the REST API, which permits up to 200) 2. Verify all reviewers are persisted correctly (e.g. via `GET /api/v4/projects/:id/merge_requests/:iid/reviewers`) 3. Open the MR in the UI — the sidebar shows only 100 reviewers with no indication that more exist 4. Make any edit via the sidebar reviewer widget (e.g. add one more reviewer) 5. Save the change ## Current Behavior - The sidebar widget loads at most 100 reviewers (the GraphQL schema-wide `default_max_page_size`) - On save, the widget reconciles the MR's reviewer set to its in-memory state (the 100 it loaded) - All reviewers beyond the first 100 are **silently removed** — no warning, no error, no system note explaining the removals - The number of reviewers silently dropped equals exactly `(total reviewers) − 100` ## Expected Behavior One or more of the following should be true: 1. **No silent data loss**: The sidebar widget should never remove reviewers it never loaded. Before saving, it should either fetch the complete reviewer set or perform an additive-only diff 2. **Pagination in the sidebar**: The reviewer/assignee widgets should paginate or fetch all results before reconciling on save, so the full set is always in memory 3. **`max_page_size` override**: The `reviewers` and `assignees` fields on `Types::MergeRequestType` should declare an explicit `max_page_size` that matches the backend limit (currently 200), rather than inheriting the schema-wide default of 100 4. **Visible truncation indicator**: If the widget cannot load all reviewers, it must clearly indicate to the user that the displayed list is incomplete, and warn before any save that would affect unloaded entries ## Root Cause Analysis Two independent constants are involved: | Constant | Location | Value | Purpose | |---|---|---|---| | `MAX_NUMBER_OF_ASSIGNEES_OR_REVIEWERS` | `app/models/concerns/issuable.rb:37` | 200 (raised from 100 in GitLab 15.9, [#366485](https://gitlab.com/gitlab-org/gitlab/-/issues/366485)) | Backend persistence limit | | `default_max_page_size` | `app/graphql/gitlab_schema.rb:33` | 100 | Schema-wide GraphQL connection default | The `reviewers` field on `Types::MergeRequestType` (`app/graphql/types/merge_request_type.rb:242`) has no `max_page_size` override. The sidebar query (`get_merge_request_reviewers.query.graphql`) requests reviewers with no explicit `first:` argument, so it is silently capped at 100 by the schema default. When the backend limit was raised to 200 in [!99163](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/99163), the GraphQL page-size cap was not updated to match, creating a gap where the API can store up to 200 reviewers but the UI can only ever see 100 of them — and will destroy the rest on the next user interaction. ## Severity Assessment This is a **silent data loss** bug. Unlike [#584885](https://gitlab.com/gitlab-org/gitlab/-/work_items/584885) (which surfaces an error when the backend limit is exceeded), this issue produces **no error, no warning, and no visible indication** that reviewers have been removed. A user performing a routine single-reviewer addition can unknowingly trigger the removal of many other reviewers, with the only evidence being system notes on the MR after the fact. The impact is proportional to the number of reviewers above 100: an MR with 115 reviewers will silently lose 15 on the next sidebar save. ## Proposed Fix - Add `max_page_size: 200` (or a named constant matching `MAX_NUMBER_OF_ASSIGNEES_OR_REVIEWERS`) to the `reviewers` and `assignees` connection fields in `Types::MergeRequestType` - And/or update the sidebar GraphQL queries (`get_merge_request_reviewers.query.graphql`, `get_mr_assignees.query.graphql`) to paginate and load the full set before reconciling on save ## Related - [#584885](https://gitlab.com/gitlab-org/gitlab/-/work_items/584885) — MR close fails with unhelpful error when reviewers exceed the 200 backend limit (different symptom: explicit error vs. silent data loss) - [#366485](https://gitlab.com/gitlab-org/gitlab/-/issues/366485) — Raised `MAX_NUMBER_OF_ASSIGNEES_OR_REVIEWERS` from 100 → 200 in GitLab 15.9 - [!99163](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/99163) — MR that implemented the backend limit increase