Add backward pagination and thread fields to MR notes facet

What does this MR do and why?

This MR adds backward paging and more fields to the notes facet of the get_merge_request MCP tool. The standalone get_merge_request_notes tool already returns all of them.

!256931 (merged) unlists get_merge_request_notes. In review, @fdegier found that agents moving to the facet would lose these fields. So that MR waits for this one.

  • Backward paging with notes_last and notes_before, plus hasPreviousPage and startCursor in pageInfo. This is the same as the notes facet of get_work_item. Mixing both directions in one call returns an error.
  • position and discussion fields on each note.
  • resolvedDiscussionsCount and resolvableDiscussionsCount on the merge request, when the notes facet is requested.

Callers that pass no new parameters get the same notes as before, with more fields.

The query complexity overrides in ee/spec/graphql/all_queries_spec.rb go up by 31 (413 to 445, and 444 to 476). The spec already marks this score as a false positive: the analyzer counts every @include facet at once, but only one facet is on per call.

References

Screenshots or screen recordings

Not applicable. This is a backend-only change, no UI.

How to set up and validate locally

  1. Run the specs:

    bundle exec rspec spec/services/mcp/tools/merge_requests/get_merge_request_service_spec.rb spec/services/mcp/tools/merge_requests/get_merge_request_tool_spec.rb ee/spec/services/ee/mcp/tools/merge_requests/get_merge_request_tool_spec.rb ee/spec/graphql/all_queries_spec.rb
  2. Optional: from an MCP client, call get_merge_request with include: ["notes"] and notes_last: 3. Check that each note has position and discussion, and that pageInfo.startCursor is present.

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 Alex Filatov

Merge request reports

Loading
Loading