fix(api): enforce rate limits for demo app creation#1679
Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the 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. 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 01e19fe0d8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const userDemoAppsCount1h = await countDemoApps(c, supabase, ownerOrg, { | ||
| since: hourlyWindowStart, | ||
| userId, | ||
| }) | ||
| if (userDemoAppsCount1h >= limits.userPerHour) { |
There was a problem hiding this comment.
The new limits in assertDemoAppCreationLimits are enforced with separate COUNT queries before the insert, so concurrent POST /app/demo requests for the same org/user can all observe the same pre-insert count and pass, then each create a demo app and exceed the configured hourly/daily caps. This is a classic check-then-act race that undermines the abuse protection this change introduces; the quota decision needs to be enforced atomically with creation (for example via a single DB-side function/lock/transaction).
Useful? React with 👍 / 👎.
riderx
force-pushed
the
riderx/limit-demo-app-abuse
branch
from
05207c1 to
470b7ce
Compare
|
1 participant
Summary (AI generated)
/app/demoto prevent abuse by authenticated low-privilege users.isPayingOrg(...)before creation.simpleRateLimit(...)rejections.bun lint:backend).Motivation (AI generated)
/app/demoallows many database writes per call and previously lacked strict anti-abuse controls. A single authenticated user with write rights could repeatedly create demo apps and trigger large write amplification across many tables, impacting availability and costs. This PR adds protective limits before writes happen.Business Impact (AI generated)
Test Plan (AI generated)
bun lint:backend/app/demoper-org/per-user throttle behavior (paid + free paths)isPayingOrgerrors are handled as expected for edge conditionsGenerated with AI