Repository navigation
Conversation
- Add specialty-level verification fields (status, reviewer, review date, rejection reason) to DoctorSpecialty via migration - Add admin endpoints for listing and reviewing per-specialty verification - Filter specialty-based search results to only include verified doctor-specialty pairs Co-Authored-By: Buffy <noreply@codebuff.com>
…buckets - Add configurable token-bucket rate limiter keyed by authenticated user ID or client IP (behind Render's proxy) - Postgres-backed store with in-memory test implementation - Return HTTP 429 with Retry-After and RateLimit-* headers - Exempt /health endpoint - Preserve existing login throttling without double-counting - Add in-memory store for tests and overhead measurement - Add unit tests for rate limit behavior Co-Authored-By: Buffy <noreply@codebuff.com>
|
@Dev-Marcy Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
|
@Dev-Marcy pls fix CI |
|
CI is failing on this PR. Typecheck fails: Please push a fix and CI will re-run. Before pushing, run |
|
Heads-up: #145 and #146 point at the same commit ( CI is red on typecheck in the rate-limit module:
Please rebase onto the latest |
|
@Dev-Marcy Thanks for the PR. It can't be merged yet. To unblock it: CI is failing. Here's what broke:
Please fix these errors and run the same steps locally before pushing ( Branch protection also requires the branch to be up to date with Push to this same branch and CI will re-run. Once it's green and conflict-free, it'll be reviewed for merge. |
|
@Dev-Marcy CI is failing on this branch, so it can't be merged yet. The errors from the latest run: Backend (typecheck + test + build) Please reproduce this locally, fix the errors above and push. CI will re-run on your next push. |
… the unit tests use the correct in-memory rate-limit state.
|
@Dev-Marcy CI is failing at typecheck after the latest push:
|
Closes #50
Summary
This PR adds a configurable, globally-applied rate limiter to DocForum. The limiter
uses a token-bucket algorithm keyed by authenticated user ID or, for
unauthenticated requests, by the correctly-resolved client IP. It is designed to
work behind Render's single proxy hop (via
X-Forwarded-Forresolution) whilekeeping the existing, stricter login throttling (issue #35) fully independent.
Design
Store
The limiter uses a pluggable
RateLimitStoreinterface with two implementations:prismaRateLimitStore— Postgres-backed. Uses raw SQLUPSERT(
INSERT ... ON CONFLICT DO UPDATE) for atomic counter increments, avoiding theread-then-write race condition that would otherwise allow concurrent requests to
bypass the limit.
MemoryRateLimitStore— in-memory implementation for fast,deterministic unit tests.
A
RateLimitRecordtable tracks per-key consumption with a 60-second slidingwindow. A scheduled prune job deletes records older than a configured threshold,
preventing unbounded store growth.
Token-bucket algorithm
Each keyed request checks consumption in the current window: