Commits.ListCommits() always returns Response.TotalItems = 0

[svanharmelen]

Can you replicate the problem with cURL? Or can you use cURL to check the results when making the same API call directly?

[kingcrunch]

It seems the header x-total is missing

x-next-page: 2
x-page: 1
x-per-page: 1
x-prev-page: 

[svanharmelen]

In the API response you mean? If so, this seems a but in the GitLab API. If not, can you replicate the problem with cURL and paste the output?

[kingcrunch]

The HTTP-header from the API-response. I used httpie for testing, so it looks different from cURL

The entire output looks like this

http GET 'https://gitlab.com/api/v4/projects/<id>/repository/commits?per_page=1&page=2' PRIVATE_TOKEN:<your-token-here>
HTTP/1.1 200 OK
CF-Cache-Status: MISS
CF-RAY: 84d9972b183b453a-TXL
Connection: keep-alive
Content-Encoding: br
Content-Type: application/json
Date: Tue, 30 Jan 2024 12:06:43 GMT
NEL: {"success_fraction":0.01,"report_to":"cf-nel","max_age":604800}
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=%2FgXUyOtRmXvc%2BxZ3mygv0G%2BdEDc6WTX2HSm61VfU6QKo899GnVKTu%2F9PZzC%2BPSgUYuz8taaeN8tWlq%2FnhEiA3ZaOfHEh%2BE7amfFsiRpdKVNqb3AJQnkItG0ANE4%3D"}],"group":"cf-nel","max_age":604800}
Server: cloudflare
Set-Cookie: ...; path=/; domain=.gitlab.com; HttpOnly; Secure; SameSite=None
Transfer-Encoding: chunked
cache-control: max-age=0, private, must-revalidate
content-security-policy: default-src 'none'
etag: W/"24d2924ba231f8e8a5d5e8ccf59e8adc"
gitlab-lb: haproxy-main-03-lb-gprd
gitlab-sv: localhost
link: <https://gitlab.com/api/v4/projects/<id>/repository/commits?id=<id>&order=default&page=1&per_page=1&trailers=false>; rel="prev", <https://gitlab.com/api/v4/projects/<id>/repository/commits?id=<id>&order=default&page=3&per_page=1&trailers=false>; rel="next", <https://gitlab.com/api/v4/projects/<id>/repository/commits?id=<id>&order=default&page=1&per_page=1&trailers=false>; rel="first", <https://gitlab.com/api/v4/projects/<id>/repository/commits?id=<id>&order=default&page=3&per_page=1&trailers=false>; rel="last"
ratelimit-limit: 2000
ratelimit-observed: 2
ratelimit-remaining: 1998
ratelimit-reset: 1706616463
ratelimit-resettime: Tue, 30 Jan 2024 12:07:43 GMT
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=31536000
vary: Origin, Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-gitlab-meta: {"correlation_id":"59dc496c6a113d9a528443e36980173a","version":"1"}
x-next-page: 3
x-page: 2
x-per-page: 1
x-prev-page: 1
x-request-id: 59dc496c6a113d9a528443e36980173a
x-runtime: 0.077426

[
    {
        ....
    }
]

[svanharmelen]

Thanks! So it looks like an issue/bug with the GitLab API. In that case I will close this issue as I cannot fix it in this package. I suggest to open an issue with GitLab in order to get this one resolved.

[fdobrovolny]

@svanharmelen

I believe this is not a bug from the GitLab side however, it was intentional:

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43159

https://gitlab.com/gitlab-org/gitlab/-/issues/389582

It seems like the x-total is returned only if the repo has less than 100 commits, and therefore, it fits into a single page.

However, I think this should return None, return the number of items on the current page, or 0 as unknown with a hint for this in comment on it, so it is probably still good to be closed.