Files
meeting-assistant/openspec/changes/azure-speech-offline-resilience/design.md
T
codex b774ccc375
PR and Push Build/Test / build-and-test (push) Successful in 18m41s
Add resilient Azure offline transcription backlog
2026-06-15 17:26:34 +02:00

2.5 KiB

Design

Current Azure Input Path

The live Azure Speech path does not use MSAL and does not record audio independently. AzureSpeechStreamingTranscriptionProvider receives AudioChunk values from StreamingSpeechRecognitionPipeline, writes them into a Speech SDK PushAudioInputStream, and emits SDK transcript events back as TranscriptionSegment values. The recording coordinator separately writes the same mixed chunks to the temporary WAV.

Transcript Markers

Add lightweight transcript marker semantics to TranscriptionSegment:

  • a marker segment writes its text directly, for example <Reconnecting... 1/5>;
  • a later real transcript segment can identify the marker it replaces;
  • the coordinator rewrites that exact marker line using the existing transcript-line reference path.

This keeps markers independent from markdown string matching and prevents a later append from being lost when the marker is replaced.

Azure Reconnect Loop

When Azure Speech reports a transient connection cancellation, the provider should stop the current Speech SDK session, leave the upstream audio channel unconsumed while disconnected so it naturally buffers, emit reconnect markers, then create a new SDK session and continue reading the buffered audio. Once the next real transcript segment arrives, it replaces the latest reconnect marker.

After configured reconnect attempts are exhausted, Azure should emit a longer disconnect marker that explains recording can continue and transcription will drain when Azure reconnects. The provider should continue retrying.

Durable Offline Backlog

If a stopped Azure Speech meeting cannot finish draining before Recording:StopProcessingTimeout, the coordinator queues the completed temporary WAV and artifact paths in a persisted offline backlog, releases the active recording slot, and keeps the WAV from startup cleanup. This lets the user start more meetings while Azure or the network is still unavailable.

The backlog processor retries queued items in the background. Each item creates a fresh speech recognition pipeline for the original launch profile, streams the queued WAV into that pipeline, rewrites the original transcript file with the finished lines, updates meeting-note and transcript metadata, runs transcript-line workflow transformations, transitions the assistant context through summarizing to finished/error, runs the normal summary pipeline, then removes the backlog item and deletes the temporary WAV. Failed processing leaves the backlog item and WAV in place for a later retry.