fix: apply rate limiting to admin delete endpoint

[Simra-08]

Description

This PR applies rate limiting to the DELETE /profiles/{slug} admin endpoint.

Previously, the POST and PATCH profile management endpoints were protected by general_rate_limit, while the DELETE endpoint only enforced admin authentication. This change ensures that all profile management admin routes consistently apply rate limiting, helping prevent excessive administrative requests.

Related Issues

Fixes #557

Changes Made

• Added general_rate_limit dependency to the DELETE /profiles/{slug} endpoint.
• Aligned the delete endpoint with the existing POST and PATCH admin routes for consistent rate limiting behavior.

Verification

• Added unit tests
• Ran pytest tests/ successfully
• [] Manually tested via code review
• (If applicable) Generated scripts pass SafetyFilter

Documentation

• Updated docs/FEATURES.md (not applicable)
• Updated CHANGELOG.md (not applicable)
• [] Code is fully documented and type-hinted

Screenshots (if applicable)

N/A

Summary by CodeRabbit

• Bug Fixes
  • Added rate limiting to profile deletion requests to prevent excessive usage and protect system stability.

[vercel]

@Simra-08 is attempting to deploy a commit to the rishabhmishra0510-5147's projects Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 73bece32-45e7-4e46-9acc-a0ab5fc61207

📥 Commits

Reviewing files that changed from the base of the PR and between 7f59a96 and 0ee358e.

📒 Files selected for processing (1)

• backend/app/api/v1/profiles.py

---

📝 Walkthrough

Walkthrough

The PR adds rate limiting to the profile deletion endpoint by injecting the general_rate_limit dependency into the delete_profile function signature. This single-line change protects the delete operation from denial-of-service attacks via rapid requests.

Changes

Profile Deletion Rate Limiting

Layer / File(s)	Summary
Rate limit wiring for profile deletion backend/app/api/v1/profiles.py	The delete_profile endpoint adds the general_rate_limit dependency as _rate_limit parameter to enforce rate limiting on profile deletion requests.

🎯 1 (Trivial) | ⏱️ ~2 minutes

🐰 A hop and a skip, one line so neat,
Guards our profiles from the rate-limit beat!
No more DoS at our delete endpoint,
Rate limiters guard where admin keys went. 🛡️

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix: apply rate limiting to admin delete endpoint' clearly and specifically summarizes the main change: adding rate limiting to the DELETE profile endpoint.
Linked Issues check	✅ Passed	The PR directly addresses issue #557 by applying the general_rate_limit dependency to the DELETE /profiles/{slug} endpoint, which was previously missing rate limiting.
Out of Scope Changes check	✅ Passed	The PR is narrowly scoped to applying rate limiting to the DELETE endpoint only; no unrelated changes are present.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

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

[github-actions]

🔍 PR Action Required

Hi @Simra-08,

We detected some items on this Pull Request that require attention:

❌ Failing CI Checks

The following check runs or commit statuses are failing (ignoring vercel):

• Frontend Build & Lint
• Backend Tests

Please resolve the issues above to proceed.

---

Last updated: Fri, 12 Jun 2026 06:43:06 GMT