Feature/cach fix tenant

[borkarsaish65]

Release Notes

• Removed cache invalidation for entity list caching after entity create, update, and delete operations, keeping only entityType cache invalidation intact
• Removed read-path caching logic in entity list method; pagination cache lookup/set for entity_list was deleted and the method now always fetches results directly
• Removed cache-first logic in modules list method that conditionally retrieved cached modules_list results; pagination/search behavior is now independent of cached data
• Updated session details caching approach to cache raw session details instead of processed response; processDbResponse computation moved to occur after the caching block

Author Contributions

Author	Lines Added	Lines Removed
borkarsaish65	21	123

[nevil-mathew]

@coderabbitai full review

[coderabbitai]

✅ Actions performed

Full review triggered.

[coderabbitai]

Walkthrough

Removed caching mechanisms across three service files. Entity and modules services no longer use cache-first retrieval strategies for list operations, and sessions service changed to cache raw data instead of processed responses. Cache invalidation logic was also removed from entity operations.

Changes

Cohort / File(s)	Summary
Cache Removal from Entity Service src/services/entity.js	Removed cache invalidation steps for entity list after create/update/delete operations; removed pagination cache lookup/set logic from list method to always fetch directly.
Cache-First Logic Removal from Modules Service src/services/modules.js	Removed cache-first conditional retrieval pattern for modules_list; removed corresponding cache population logic; list now always constructs filter and queries directly.
Sessions Caching Strategy Revision src/services/sessions.js	Changed details method to cache raw session data with minor field deletions instead of processed data; moved processDbResponse computation to after caching block.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

Hop, skip—the cache must go! 🐰
Three services shed their stored glow,
Fresh queries dance, no delays in sight,
Direct database calls feel so right,
Clean and speedy, fast we grow!

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'Feature/cach fix tenant' is vague and contains apparent typos ('cach' likely means 'cache'); while it broadly references caching fixes for tenant functionality matching the PR objectives, it lacks clarity about the specific changes.	Clarify the title to be more specific, such as 'Remove entity and module list caching logic' or 'Fix cache handling in tenant services', and correct apparent typos for better clarity.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ 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.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/services/sessions.js (1)

1762-1772: ⚠️ Potential issue | 🔴 Critical

Cache hit returns unprocessed session data—API responses differ depending on cache state.

The details() function has an inconsistency: when a session is retrieved from cache (line 1462), it is returned directly without calling processDbResponse. However, when the same session is fetched from the database (line 1547), it is processed by processDbResponse before being returned (line 1772).

This means the cache stores raw sessionDetails (with entity-type fields in their raw format), and the cache hit path returns this raw data to clients, while the cache miss path returns processed data with transformed entity-type fields. API clients will receive different response formats depending on whether the cache was hit or missed.

Solution: Either call processDbResponse on the cached response before returning it (line 1539), or store the processed result in the cache instead of the raw data (line 1768).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/services/sessions.js` around lines 1762 - 1772, The cached session path
in details() returns raw sessionDetails while the DB path runs
utils.processDbResponse(sessionDetails, validationData) before returning,
causing inconsistent API responses; fix by ensuring cached responses are
processed the same way—either call utils.processDbResponse(...) on the cached
session before returning it in details(), or change the cache write
(cacheHelper.sessions.set with cacheCopy) to store the processed result (result
of utils.processDbResponse) instead of raw sessionDetails so both cache hits and
misses return the same processed payload.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@src/services/sessions.js`:
- Around line 1762-1772: The cached session path in details() returns raw
sessionDetails while the DB path runs utils.processDbResponse(sessionDetails,
validationData) before returning, causing inconsistent API responses; fix by
ensuring cached responses are processed the same way—either call
utils.processDbResponse(...) on the cached session before returning it in
details(), or change the cache write (cacheHelper.sessions.set with cacheCopy)
to store the processed result (result of utils.processDbResponse) instead of raw
sessionDetails so both cache hits and misses return the same processed payload.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 2f9c6fd3-548a-4f8e-9d8c-ea06b78d18cb

📥 Commits

Reviewing files that changed from the base of the PR and between 72659c4 and d63bae9.

📒 Files selected for processing (3)

• src/services/entity.js
• src/services/modules.js
• src/services/sessions.js

[nevil-mathew]

Why are we storing the raw response in the cache? Has the cache hit flow been updated to handle this new logic? What’s the reason behind this change?

[borkarsaish65]

The change was needed because processDbResponse() transforms type into an object { label: "PUBLIC", value: "PUBLIC" }. When the processed result was cached, it was breaking the session update and delete API flows — the comparison sessionDetail.type != bodyData.type was always true (object vs string), triggering CANNOT_EDIT_MENTOR_AND_TYPE incorrectly.

Storing raw data fixes that comparison. The cache-hit path in the details endpoint has been verified and works correctly with the raw data.