Lift blame line-range cap from 100 to 1000 in BlameResolver

Summary

Follow-up from the spike #586593 (closed) (see investigation summary).

Lift the current from_line + 100 cap in the GraphQL blame resolver to from_line + 1000 so the frontend can request progressively larger blame ranges as part of the slow-start ramp strategy validated in the spike.

Context

The spike's benchmark (!234332 (closed)) confirmed that for files with extensive commit history, the cost of a RawBlame call is dominated by history walking, not by the requested line range size. A 14× larger range (70 → 1000 lines) only costs 22–48% more Gitaly time depending on file position:

Range Median Gitaly time (per-position medians, local)
70 2553 – 3013 ms
250 3125 – 3211 ms
600 3324 – 3615 ms
1000 3644 – 3960 ms

This means we can dramatically reduce the number of blame requests a user makes when scrolling through a large file, without proportionally increasing per-request cost. The frontend ramp (70 → 250 → 600 → 1000) needs the backend cap raised to 1000 before it can be implemented.

Proposal

  • Lift the from_line + 100 cap to from_line + 1000 in Resolvers::BlameResolver#validate_line_params!
  • Update the corresponding resolver spec to cover the new cap
  • Verify no other callers rely on the 100-line ceiling

Out of scope

  • Frontend ramp implementation (tracked separately as a follow-up to this issue)
  • Optimizing the first-paint blame request (Git-level limit, see #586593 (closed))
  • Blame caching (mentioned in #586593 (closed) discussion but not pursued in this iteration)

Related

Edited by 🤖 GitLab Bot 🤖