Spike: Replace TagsFinder with Gitlab::Git::Finders::RefsFinder for Tags API search

Current problem

When the Tags API (GET /projects/:id/repository/tags?search=) receives a search term, TagsFinder fetches all tags from Gitaly and filters them in Ruby (by_search), instead of asking Gitaly to return only the matching tags. The cost scales with the total number of tags in the repository, not with the number of results, so repositories with many tags are slow. A customer with 10,000+ tags has reported ~20s API responses (see #372051).

Branches were already migrated to Gitaly-side search via Gitlab::Git::Finders::RefsFinder (!229216 (merged), behind the use_new_branches_finder_api feature flag). This spike evaluates doing the same for tags.

The code already flags the gap: lib/gitlab/pagination/gitaly_keyset_pager.rb contains the comment # Gitaly pagination does not support tags search.

Scope: tags + search + REST API only.

Questions to answer

  1. Does RefsFinder (with ref_type: :tags) return all the data the Tags API response needs — annotated-tag messages, signatures (TagsFinder.batch_load_tag_signature_data), dereferenced commit, and release info? If not, what is missing?
  2. Is a Gitaly change required (e.g. tag peeling support in ListRefs), or can this be done purely in Rails? This is the go/no-go question for the timeline.
  3. Does Gitaly support search + pagination together for tags via ListRefs? (The old path explicitly does not.)
  4. How does the case-insensitive (ignore_case) performance issue found during the branches rollout (#594929 (closed)) apply to tags, and does the branches workaround transfer?

Outcome of this spike

A concrete implementation plan for migrating Tags API search to Gitaly:

  • Sized follow-up issues
  • Whether a Gitaly change is needed (and if so, the cross-team / release-cycle dependency)
  • A recommendation on whether and how to proceed

Related

Edited by 🤖 GitLab Bot 🤖