notify-bridge/RELEASE_NOTES.md

v0.3.1 (2026-04-22)

Follow-up perf pass on top of v0.3.0's polling overhaul — extends the same caching discipline to the bot-command read paths so repeat /random, /latest, /memory, etc. against the same album don't each refetch a multi-megabyte album body or pay for a full server-wide /api/shared-links listing.

Performance

• TTL-cache GET /api/albums/{id} responses — 60 s TTL, 32-entry FIFO cap, keyed by (server_digest, album_id). Module-scoped rather than instance-scoped because ImmichClient is constructed fresh per request in several places (api/providers.py, services/action_runner.py, command handlers), so an instance cache would never survive a second caller. Mirrors the existing _users_cache pattern. (3b7808a)
• TTL-cache the bucketed shared-links map — 60 s TTL, keyed by server digest. /api/shared-links has no per-album filter, so every get_shared_links(album_id) call was already paying for the full server-wide list; now one fetch serves every album until the TTL elapses. (3b7808a)
• Collapse concurrent cache misses to one fetch — async lock with an under-lock re-check around the album / shared-links populate step, so a burst of parallel commands hitting the same cold key issues one HTTP call instead of N. (3b7808a)
• use_cache=False escape hatch on mutation / event-detection paths — ImmichActionExecutor.execute (which diffs the current album state to decide what to add) and ImmichServiceProvider.poll's full-fetch path (where a stale entry would silently delay asset-removal events) explicitly bypass the cache. Non-cached fetches still populate it for subsequent readers. (3b7808a)

---

All Commits

• 3b7808a — perf(immich): TTL cache for album bodies and shared-link listings (alexei.dolgolyov)