DocFast session 142: BUG-108/109/110 fixed, 547 tests

This commit is contained in:
Hoid 2026-03-07 20:07:19 +01:00
parent a3fa0d8333
commit 9d7bc02081
4 changed files with 66 additions and 2 deletions

View file

@ -1,3 +1,27 @@
## BUG-110: POST /v1/recover initial request still uses in-memory cache only — recovery email not sent across pods
- **Date:** 2026-03-07
- **Severity:** MEDIUM
- **Issue:** `POST /v1/recover` uses `getAllKeys()` to find a user by email. BUG-107 added DB fallback to `/v1/recover/verify` but NOT to the initial `/v1/recover` route. If the key exists in DB but not in this pod's cache, the route returns "recovery_sent" but never actually sends the verification email (silently skips).
- **Impact:** Users may be unable to recover their API key if they hit a pod that doesn't have the key cached. Silent failure — same "recovery_sent" response regardless.
- **Fix:** Add DB fallback in `POST /v1/recover` — if `getAllKeys().find()` returns nothing, query DB by email before deciding to skip sending.
- **Status:** ✅ FIXED — commit d376d58. DB fallback sends recovery email when cache miss. 2 TDD tests added. 547 tests total.
## BUG-109: updateKeyEmail only checks in-memory cache — email change may silently fail across pods
- **Date:** 2026-03-07
- **Severity:** MEDIUM
- **Issue:** `updateKeyEmail()` in `src/services/keys.ts` only checks `keysCache` (in-memory). In 2-replica production, if the email-change verify route on one pod updates the DB directly but the billing webhook `customer.updated` calls `updateKeyEmail` on another pod where the key isn't cached, the function returns `false` without checking DB.
- **Impact:** Unlikely to trigger (email-change uses direct DB, not this function), but `updateKeyEmail` is exported and could be used elsewhere. Code quality issue — same pattern as BUG-106.
- **Fix:** Add DB fallback: query `api_keys` table by key when not found in cache.
- **Status:** ✅ FIXED — commit d376d58. DB fallback + cache hydration. 2 TDD tests added. 547 tests total.
## BUG-108: updateEmailByCustomer only checks in-memory cache — Stripe email sync silently fails across pods
- **Date:** 2026-03-07
- **Severity:** MEDIUM
- **Issue:** `updateEmailByCustomer()` in `src/services/keys.ts` only checks `keysCache` (in-memory). In 2-replica production, if a Stripe `customer.updated` 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's email change from Stripe is silently lost.
- **Impact:** Email sync from Stripe billing silently fails. Customer's email in DocFast DB diverges from Stripe. Recovery emails go to wrong address.
- **Fix:** Add DB fallback: query `api_keys` table by `stripe_customer_id` when not found in cache, then update email in DB and hydrate local cache.
- **Status:** OPEN
## BUG-107: Recover route uses in-memory cache only — recovery fails silently across pods
- **Date:** 2026-03-06
- **Severity:** MEDIUM