Actions API: invalid per_page values (<=0) silently return 30 results instead of 400 error

[ramzanbhutto]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

API

Body

Endpoint:
GET /repos/{owner}/{repo}/actions/runs

Expected behavior:
Passing an invalid per_page value (0 or negative) should return a 400 Bad Request error.

Actual behavior:
The API silently ignores the invalid value and returns 30 results (the default page size), with no error or warning in the response.

Steps to reproduce:

1. https://api.github.com/repos/microsoft/vscode/actions/runs?status=failure&per_page=0
2. https://api.github.com/repos/microsoft/vscode/actions/runs?status=failure&per_page=-1

Both return 30 workflow_runs with a 200 OK status.

Tested on multiple repos - same behavior on all of them.

Why this matters:
A client passing per_page=0 expecting an empty result or an error will silently get data, which can cause bugs that are hard to detect.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[tahleho3968]

Confirmed — and this isn't specific to the Actions API. It's GitHub-wide REST pagination behavior, so it looks intentional rather than a bug in this one endpoint.

I reproduced it on the same endpoint (/repos/microsoft/vscode/actions/runs):

per_page	results returned
0	30 (default)
-1	30 (default)
30	30
100000	100 (capped)

So out-of-range values are clamped, not rejected: <= 0 is treated like "not specified" and falls back to the default of 30, and > 100 is capped at 100. The REST pagination docs describe per_page as "results per page (max 100)", which only hints at the upper bound — the lower-bound behavior is undocumented, which is the real gap here.

It's a common API design choice (a server rarely 400s on a query-param edge case), but you're right that it's easy to trip over: a client sending per_page=0 believing it means "no results" silently gets 30.

Practical takeaway for builders:

• Validate on the client: clamp per_page to 1..100 yourself before sending.
• Treat the item count in the response as authoritative — if you asked for 0 and get 30, that's the signal the param wasn't honored.

If you'd like the behavior changed (e.g. 422 for out-of-range values), that's a reasonable product suggestion for the team — as it stands, the docs should at least spell out that values <= 0 fall back to the default.

[ramzanbhutto]

@tahleho3968
Thanks for the explanation! Agreed, a quick doc note like "values ≤ 0 fall back to default (30)" would save a lot of confusion. or, returning 422 for out-of-range values like this pagination issue would be a cleaner signal to API consumers.