Bump global rate limit to 360 and add JSON body on 429

[rainxchzed]

Summary

Two related fixes uncovered by burst-testing the rate-limit boundaries on production.

1. Global bucket: 120 → 360 / min / IP

The global rate-limit bucket is evaluated alongside per-route buckets (search, badges, events, etc.). Whichever is tighter wins. With global at 120 and search at 240, the search bump from PR #4 had zero effect for any same-IP burst — global tripped first.

Verified by bursting /v1/releases from a single IP: hit 429 at request 121, exactly at the global ceiling, never reached the search bucket's 240.

Real client burst pattern that motivates the bump:

• Cold start fan-out: /announcements + /categories + /topics + first /search ≈ 4-7 calls in seconds.
• Details-page open: /repo + /releases + /readme + /user = 4 calls.
• Profile screen: /users/{u}/repos + /users/{u}/starred = 2 calls.

A user opening a few details pages plus the profile screen burns ~30 slots in under a minute. 120 was too tight. 360 leaves the per-route ceilings (search=240, badges=60, events=3) as the binding limit on real traffic.

VPS perf: 120 req/sec on 4 vCPU is fine. Headroom remains.

2. 429 response: empty body → JSON body

Ktor's RateLimit plugin returns 429 + Retry-After but with an empty response body. Clients can't surface a useful error message without parsing headers — and many client-side error pipelines expect a JSON body.

New StatusPages handler for 429 returns:

{ "error": "rate_limited", "message": "Retry after 24s" }

The Retry-After header set by the RateLimit plugin is preserved. Clients that already read Retry-After keep working; clients that read the body now get a parseable error.

Out of scope (deferred)

• Mirroring x-ratelimit-* onto 429 itself — would require querying internal RateLimit plugin state, no public API. Workaround: client uses Retry-After + the X-RateLimit-* from the most recent 2xx response.
• ASN/CGNAT bypass via installation-id — separate work.

Test plan

• ./gradlew test green.
• After deploy, burst /v1/releases from a single IP via api-direct.github-store.org; expect 429 at request ~241 (search-bucket ceiling) instead of ~121 (old global).
• Confirm 429 response body is {"error":"rate_limited",...} and Retry-After is present.

[coderabbitai]

Warning

Rate limit exceeded

@rainxchzed has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 14 minutes and 56 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0c704029-3f6d-4e46-a32d-96e0a88725cf

📥 Commits

Reviewing files that changed from the base of the PR and between dc9a736 and 3699858.

📒 Files selected for processing (1)

• src/main/kotlin/zed/rainxch/githubstore/Plugins.kt

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch raise-global-and-429-body

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Review rate limit: 0/1 reviews remaining, refill in 14 minutes and 56 seconds.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}