fix: read user settings fresh instead of from a per-process cache

[HardMax71]

The user settings service kept a 5-minute cache in each API process, and the API container runs two gunicorn workers (WEB_CONCURRENCY defaults to 2 in the Dockerfile). A read that landed on the other worker after an update returned the old settings for up to 5 minutes. An update handled there merged onto that stale copy too, so its response could carry an old theme. I hit it while checking #333 in a browser: right after toggling the theme, the GET sometimes answered with the previous one. Once #333 merges, the frontend applies the theme from the settings query on every refetch, so this would show as a theme flipping back.

Every read now rebuilds from the latest snapshot and the events after it. That's two MongoDB queries and at most ten events, since a snapshot is written every ten. cachetools had no other user, so it's dropped from the dependencies.

The new unit test runs two services over one store, standing in for two workers, and fails on main (auto == dark). The e2e test that only checked the cache hit is replaced by one that reads right after an update. Unit tests, ruff, mypy and the orphan check pass. The non-k8s e2e suite passes apart from the usual k3s-only saga, notification and SSE tests.

---

Summary by cubic

Fixes stale user settings when an update goes through one API worker and a read hits another, since each worker kept its own 5-minute cache. Reads now rebuild from the latest snapshot and the events after it, so updates are visible immediately; updates no longer merge onto a stale cached copy.

• Removed the per-process TTLCache and the now-unused cachetools and types-cachetools dependencies.
• Each read costs two MongoDB queries and at most ten events, since a snapshot follows every ten.
• Replaced the e2e cache-hit test with one that reads right after an update, and added a unit test where a second service stands in for another worker.
• Updated architecture docs to match.

^{Written for commit 5b08771. Summary will update on new commits.}

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 93a3d3f6-20ed-4a96-b5c4-e8a5c653b308

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Flag	Coverage Δ
backend-e2e	82.87% <100.00%> (-0.08%)	⬇️
backend-unit	72.33% <100.00%> (-0.02%)	⬇️
frontend-unit	87.85% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
backend/app/services/user_settings_service.py	98.73% <100.00%> (-0.23%)	⬇️

... and 1 file with indirect coverage changes

Components	Coverage Δ
Backend	91.35% <100.00%> (-0.03%)	⬇️
Frontend	87.85% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.