Description
Enforce a per-supplier daily-cap on booking-intent creation (default 500/day) with a 429 response and X-DailyCap-Reset header, plus an admin override on the supplier profile.
Requirements and context
- Must be secure, tested, and documented
- Should be efficient and easy to review
- Relevant code:
src/routes/bookingIntents.ts, src/services/supplierCap.ts
Suggested execution
- Fork the repo and create a branch
git checkout -b feat/supplier-daily-cap
- Implement changes
- Track counter in Redis keyed by
supplier:{id}:booking:{yyyy-mm-dd} with TTL 26h
- Return 429 with reset header when cap exceeded
- Add admin override CRUD on
PUT /admin/suppliers/:id/booking-cap
- Validate security and correctness assumptions
Test and commit
- Run tests
- Cover edge cases
- cap boundary (exactly at cap), midnight rollover, admin override to 0 (soft block), Redis miss
- Include test output and notes
Example commit message
feat: per-supplier daily booking cap
Guidelines
- Minimum 95 percent test coverage
- Clear documentation
- Timeframe: 96 hours
Description
Enforce a per-supplier daily-cap on booking-intent creation (default 500/day) with a 429 response and
X-DailyCap-Resetheader, plus an admin override on the supplier profile.Requirements and context
src/routes/bookingIntents.ts,src/services/supplierCap.tsSuggested execution
git checkout -b feat/supplier-daily-capsupplier:{id}:booking:{yyyy-mm-dd}with TTL 26hPUT /admin/suppliers/:id/booking-capTest and commit
npm testExample commit message
feat: per-supplier daily booking capGuidelines