API /issue endpoint pagination links don't account for filtering #3515

Closed
opened 2025-11-02 05:15:35 -06:00 by GiteaMirror · 4 comments
Owner

Originally created by @jerrykan on GitHub (Jun 26, 2019).

  • Gitea version (or commit ref): 1.9.0+dev-377-g5908bb103
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant

Description

When making an API request to the /issues endpoint the URLs in the Link response header don't account for the number of issues that have been filtered out by parameters. This is related to #7259

In the example-repo there are 23 issues, 3 of which have been closed leaving on 20 open. Doing a API request with no query parameter only returns open issues, so there should only be 2 pages of issues returned:

curl -I -H  "accept: application/json" -H  "authorization: Basic XXXXXX" -X GET "https://try.gitea.io/api/v1/repos/jerrykan/example-repo/issues"
HTTP/2 200 
content-type: application/json; charset=UTF-8
date: Wed, 26 Jun 2019 02:17:57 GMT
link: <https://try.gitea.io/api/v1/repos/jerrykan/example-repo/issues?page=2>; rel="next",<https://try.gitea.io/api/v1/repos/jerrykan/example-repo/issues?page=3>; rel="last"
set-cookie: XXXXXX
set-cookie: XXXXXX
set-cookie: XXXXXX
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN

However, as can be seen in the example above the Link response header contains a rel="last" that is /issues?page3.

Sending a request to the supplied URL returns no data:

curl -H  "accept: application/json" -H  "authorization: Basic XXXXXX" -X GET "https://try.gitea.io/api/v1/repos/jerrykan/example-repo/issues?page=3"

I would expect the Link header to return something like:

link: <https://try.gitea.io/api/v1/repos/jerrykan/example-repo/issues?page=2>; rel="next",<https://try.gitea.io/api/v1/repos/jerrykan/example-repo/issues?page=2>; rel="last"
Originally created by @jerrykan on GitHub (Jun 26, 2019). - Gitea version (or commit ref): 1.9.0+dev-377-g5908bb103 - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (provide example URL) - [ ] No - [ ] Not relevant ## Description When making an API request to the `/issues` endpoint the URLs in the `Link` response header don't account for the number of issues that have been filtered out by parameters. This is related to #7259 In the [`example-repo`](https://try.gitea.io/jerrykan/example-repo/issues) there are 23 issues, 3 of which have been closed leaving on 20 open. Doing a API request with no query parameter only returns open issues, so there should only be 2 pages of issues returned: ``` curl -I -H "accept: application/json" -H "authorization: Basic XXXXXX" -X GET "https://try.gitea.io/api/v1/repos/jerrykan/example-repo/issues" ``` ``` HTTP/2 200 content-type: application/json; charset=UTF-8 date: Wed, 26 Jun 2019 02:17:57 GMT link: <https://try.gitea.io/api/v1/repos/jerrykan/example-repo/issues?page=2>; rel="next",<https://try.gitea.io/api/v1/repos/jerrykan/example-repo/issues?page=3>; rel="last" set-cookie: XXXXXX set-cookie: XXXXXX set-cookie: XXXXXX x-content-type-options: nosniff x-frame-options: SAMEORIGIN ``` However, as can be seen in the example above the `Link` response header contains a `rel="last"` that is `/issues?page3`. Sending a request to the supplied URL returns no data: ``` curl -H "accept: application/json" -H "authorization: Basic XXXXXX" -X GET "https://try.gitea.io/api/v1/repos/jerrykan/example-repo/issues?page=3" ``` ``` ``` I would expect the `Link` header to return something like: ``` link: <https://try.gitea.io/api/v1/repos/jerrykan/example-repo/issues?page=2>; rel="next",<https://try.gitea.io/api/v1/repos/jerrykan/example-repo/issues?page=2>; rel="last" ```
GiteaMirror added the issue/staletype/bug labels 2025-11-02 05:15:35 -06:00
Author
Owner

@stale[bot] commented on GitHub (Aug 25, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Aug 25, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
Author
Owner

@jerrykan commented on GitHub (Aug 25, 2019):

I believe this is still a valid bug

@jerrykan commented on GitHub (Aug 25, 2019): I believe this is still a valid bug
Author
Owner

@stale[bot] commented on GitHub (Oct 24, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Oct 24, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
Author
Owner

@stale[bot] commented on GitHub (Nov 7, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Nov 7, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#3515