session 137: BUG-106/107 fixed, multi-pod cache consistency

projects/business/memory/bugs.md

@@ -1,3 +1,19 @@
+## BUG-107: Recover route uses in-memory cache only — recovery fails silently across pods
+- **Date:** 2026-03-06
+- **Severity:** MEDIUM
+- **Issue:** `POST /v1/recover` and `/v1/recover/verify` use `getAllKeys()` (in-memory cache) to find a user's key by email. In a 2-replica setup, if the key was created or email changed on another pod, the cache is stale. Recovery silently returns "recovery_sent" without actually sending an email (because it doesn't find the key), or verify returns "No API key found" despite the key existing in DB.
+- **Impact:** Users may be unable to recover their API key if they hit the "wrong" pod. Silent failure — no error shown.
+- **Fix:** Fall back to DB query when in-memory lookup fails.
+- **Status:** ✅ FIXED — commit b964b98. DB fallback in recover/verify endpoint. 2 TDD tests added (recover-db-fallback.test.ts). 520 tests total.
+
+## BUG-106: downgradeByCustomer only checks in-memory cache — cancellations can silently fail
+- **Date:** 2026-03-06
+- **Severity:** HIGH
+- **Issue:** `downgradeByCustomer()` in `src/services/keys.ts` only checks `keysCache` (in-memory). In 2-replica production, if a Stripe cancellation webhook hits a pod that doesn't have the key cached (pod restart, key created on other pod), the function returns `false` without checking DB. Customer keeps Pro access despite canceling their subscription.
+- **Impact:** Revenue leakage — canceled customers retain Pro tier indefinitely. Silent failure with no error log.
+- **Fix:** Add DB fallback: query `api_keys` table by `stripe_customer_id` when not found in cache, then update tier in DB and hydrate local cache.
+- **Status:** ✅ FIXED — commit b964b98. DB fallback + cache hydration. 2 TDD tests added (keys-downgrade.test.ts). 520 tests total.
+
 ## BUG-105: Go and PHP examples show non-existent SDK code
 - **Date:** 2026-03-05
 - **Severity:** MEDIUM