Bug review fixes: calendar repeats and alarms, Sentry privacy filter, rate-limit memory, dead word-stem patterns

Merged
BI
1mo ago
+975-110

Summary

  • Calendar: a monthly series on the 29th–31st drifted to the 28th after a short month, and the exported RRULE skipped short months in Google/Apple/Outlook. Now anchored and clamped (BYMONTHDAY=28..d;BYSETPOS=-1).
  • Calendar: repeating events now carry a relative VALARM so every occurrence alerts; long-running series (400+ occurrences old) reach the visible range again.
  • Sentry log scrubber: the suicid stem matched no real word and plurals were missed; a lone clinical word also bypassed the check. Both fixed, key allowlist unchanged.
  • Rate limiter: the durable deny cache was unbounded; now capped at 2000 like the in-memory limiter.
  • Dead word stems (escalat, contraindicat, prescrib, psychiatr, pregnan, oncolog, …) inside \b…\b matched no real word in 61 regexes. Fixed in two commits: clinical-output/categorisation (d6dd6f0f9) and ranking-protected retrieval code (661ccbb64, revertable alone).
  • Three sealed hazard-control files still carry the defect; withheld for owner clinical re-review (queued in the issues inbox with two other follow-ups).
  • CI repair (2026-09-28): merged main twice; the migration was re-dated from 20260927201500 to 20260928091500 (SQL unchanged) because main gained 20260927202500_on_call_named_cover; hashes resealed and the drift manifest regenerated by local replay; the pinned retrieval-plan cache-key fingerprint in rag-site-content-freshness updated for the deep-memory v2 bump; the phone-scroll test helper now applies safe-area insets via an init script so a page reload cannot drop them.

Areas touched: Answer engine, Personal practice, App experience, Data platform and access, Source intake and indexing, Knowledge and records
RAG impact: behaviour change — canary pair #105 (67d961107, pre-change baseline, already failing on main per #J8SJQ9) -> post-merge run pending; compare retrieval recall and per-case rr, revert 661ccbb64 alone on regression

Verification

  • Checks run: new tests red before each fix and green after. Full offline suite after the stem fixes: Tests 5 failed | 20001 passed — the 5 were the clinical-hazard drift check on the three sealed files, resolved by reverting those edits (clinical-hazard-controls.test.ts: Tests 31 passed). Focused calendar/reminder/sentry/rate-limit suites 86 passed, 16 passed, 25 passed. Changed-file ESLint clean. CI repair: rag-site-content-freshness + rag-cache-invalidation + migration-history-guards: Tests 57 passed; Migration immutability guard passed: 284 shipped migrations unchanged.; phone-scroll browser specs locally: 95 passed. Browser suites and verify:full left to CI.

Risk and rollout

  • Risk: 661ccbb64 changes which retrieval/extraction signals fire; offline tests unchanged, live effect unmeasured until the post-merge canary. d6dd6f0f9 changes answer-line grouping and document categories.
  • Rollback: revert 661ccbb64 and/or d6dd6f0f9 individually.
  • Provider or production effects: None from this session. The post-merge canary is owner-run.

Notes

  • GitHub's two high Dependabot alerts are one nltk advisory (GHSA-8mgp-746c-j5xp) with no patched release; not reachable from worker code. Queued as P3.

Post-merge steps

This PR carries a migration (supabase/migrations/20260928091500_accept_rag_deep_memory_v2.sql), so merging applies it to the live database. Merge by hand inside an approved window, not with auto-merge.

The migration makes commit_document_deep_memory_generation accept rag-deep-memory-v1 or -v2 legacy local-worker sections and sets rag_response_cache.indexing_version to default to v2. The code now stamps rag-deep-memory-v2. Until reindexed, v1 documents keep serving their old embedding fields: the fields that were missing escalation and contraindication sentences. The response cache is keyed on the new version, so it starts cold after deploy.

For the owner, after merge (nothing below was run by this session, against any database):

  1. Confirm the migration applied: run npm run check:migration-history and npm run check:drift against live (service-role env). Both should be green, and the column default should read 'rag-deep-memory-v2'.
  2. Governed reindex: re-embed documents whose chunks or sections still carry rag_indexing_version = 'rag-deep-memory-v1', using the repo's governed path (npm run reindex / backfill with its health and cleanup checks: reindex:health, reindex:cleanup-staged). Go in bounded batches, following the reindex runbook and AGENTS.md. v1 sections remain valid local-worker artifacts during the rollout, so a partial reindex is safe.
  3. Canary: after the reindex, run the post-merge canary pair (baseline #105 in RAG impact: above) and compare retrieval recall and per-case rr. Check specifically that escalation and contraindication queries now retrieve the clinical_action / chunk_high_yield fields. If it regresses, revert per the RAG impact: line.
  4. When no v1 rows remain, a later migration may drop v1 from the accepted list (optional).

🤖 Generated with Claude Code

https://claude.ai/code/session_01Mjb5JwByALykep3QhDzrtZ
https://claude.ai/code/session_012F1wsGKLXLtux2NXaJ5ifS