Summary
Keep the pagination loop-cap test aligned with the production pagination limit.
Required change
In internal/api/client_test.go, update the TestProjects pagination-loop subtest so wantPages references the production maxPages constant rather than duplicating the numeric literal (1000).
Rationale
The test should remain coupled to the actual pagination cap. If maxPages changes while the test keeps a hard-coded value, the assertion can become a hang-vs-fail race rather than reliably validating the limit.
Affected area
internal/api/client_test.go- Pagination loop protection in
internal/api/client.go
Acceptance criteria
- The test declares
wantPages from maxPages.
- The existing test continues to verify that pagination stops at the configured cap.
Backlinks:
Requested by: @khvn26
Summary
Keep the pagination loop-cap test aligned with the production pagination limit.
Required change
In
internal/api/client_test.go, update theTestProjectspagination-loop subtest sowantPagesreferences the productionmaxPagesconstant rather than duplicating the numeric literal (1000).Rationale
The test should remain coupled to the actual pagination cap. If
maxPageschanges while the test keeps a hard-coded value, the assertion can become a hang-vs-fail race rather than reliably validating the limit.Affected area
internal/api/client_test.gointernal/api/client.goAcceptance criteria
wantPagesfrommaxPages.Backlinks:
Requested by: @khvn26