ML→Core Write-Back Resilience

Status: Draft Author: Ryan Nel Date: 2026-05-01

Problem

After post-meeting processing completes, ML writes results to Core REST: transcript segments, synthesis artefacts (headline, summary, topics, talking points), transcription status transitions, and system-generated tasks. If Core is unavailable at delivery time, ML retries with exponential backoff. If Core remains down beyond the retry budget, results are lost — the user sees a permanently stuck "Processing…" state with no recovery path.

The same risk applies to live-session write-backs (transcript segment appends, talking points, tasks) if the Core REST endpoints become unreachable while the ML WebSocket remains connected. Today, ML has no durable store for pending write-backs and no mechanism to resume delivery after a prolonged Core outage.

Appetite

2–3 weeks. The core problem is well-understood (durable outbox or Pub/Sub fallback), but the solution must handle idempotent delivery, ordering constraints (status transitions must arrive in order), and partial-failure scenarios (some artefacts delivered, others not).

Why Now

The Meeting Recording bet is the first feature where ML produces durable artefacts that users expect to appear reliably. During live recording, the ML WebSocket provides a natural retry path — if the WebSocket is connected, Core is reachable. But post-meeting processing runs asynchronously via Pub/Sub, and the write-back window may not overlap with Core availability. The current retry-and-hope approach is acceptable for a first release, but the failure mode is user-visible and unrecoverable without manual intervention.