[HIGH] — `GET /campaigns` cache key omits `page`, `limit` and `sortBy`, serving identical payloads for vastly different requests

[Alqku]

Severity: High
Type: Bug
Scope: Campaigns
Labels: bug, Official Campaign

Description

CampaignsController.browseCampaigns (src/campaigns/campaigns.controller.ts, lines ~85–101) determines its cache key via generateCacheKey(query) which only concatenates category, status, and search (lines ~177–187). page, limit, and sortBy are ignored.

Consequences:

• Two clients requesting page 1 and page 2 of the same filter receive the same first page, with subsequent pages perpetually empty or duplicated.
• Different sortBy values (mostFunded, endingSoon, newest) collide in the cache, and whichever request writes last wins for the TTL window.
• Users browsing pagination or experimenting with sort orders repeatedly hammer the database instead of being served from cache; conversely they read stale results.

Recommendation

• Include every filter, pagination, and sort token in the key — e.g. campaigns:c=foo:s=ACTIVE:q=text:p=2:l=20:sort=mostFunded.
• Hash the key when the input is unbounded (search string can be 200+ chars) so Redis does not store huge keys.
• Add an integration test that asserts different page/sortBy values produce distinct cached entries.

---

[barry01-hash]

i will love to work on this issue

[grantfox-oss]

🦊 GrantFox — @barry01-hash has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #5)
2. Your PR will be reviewed by the OrbitChainLabs maintainers

Good luck! Track your progress on GrantFox.