<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=536183) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=536183) </details> <!--IssueSummary end--> ### Summary We recently discovered [an issue](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/188241) with time discrepancies between client and server in the blob query API for open MRs because currently the API for `getOpenMrsForBlobPath` requires the frontend to pass a `created_after` date. This created inconsistent behavior where the same query might fail depending on when it's executed during the day. The frontend has aleady fixed this by [passing the UTC time as part of the request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/188241), but it might still be worth simplifying the API to prevent similar issues in the future. This issue proposes that we eliminate potential client/server time discrepancies by accepting a `lookback_period: 30` (30 max) instead of a date. **Benefits:** - Simplifies frontend code by removing the need for date calculations - Makes the API more intuitive (users think in terms of "show me MRs from the last X days") - Prevents unexpected validation failures - More consistent behavior regardless of when the query is executed **Notes:** - The backend could calculate the appropriate date using `lookback_period.days.ago`. - We should set the maximum value (e.g., 30 days) to prevent performance issues. - The existing date-based parameters could be maintained for backward compatibility but marked as deprecated (not sure what the process for this is on the backend).