#777·meetily

fix(storage): report and repair partial transcript sidecar saves

Author: safvanatzackCreated Sep 7, 2026Updated Sep 7, 2026
Labelsbugbackend

Problem

Import and retranscription commit canonical SQLite state before writing transcripts.json and metadata.json. A later sidecar write or rename failure is logged as a warning, but the operation still emits unqualified completion.

For retranscription, SQLite can contain replacement version B while the user-accessible transcripts.json remains at version A. For import, metadata can advertise a completed transcript file that is absent.

SQLite-first ordering alone is not the defect. The defect is clean completion without a partial-save result or verified reconciliation.

User impact

The in-app meeting remains usable because supported reads use SQLite, but meeting-folder backups, manual inspection, and future folder-based consumers can observe missing or stale transcript artifacts.

Reachability and evidence

Concrete triggers include disk-full, permission changes, redirected or synchronized folder failures, and Windows rename sharing restrictions.

  • Shared atomic transcript writer: frontend/src-tauri/src/audio/common.rs:71-102
  • Import commit and warning-only sidecars: frontend/src-tauri/src/audio/import.rs:641-674,690-740
  • Import metadata contract: frontend/src-tauri/src/audio/import.rs:879-907
  • Retranscription commit and warning-only sidecars: frontend/src-tauri/src/audio/retranscription.rs:430-499
  • Retranscription metadata contract: frontend/src-tauri/src/audio/retranscription.rs:724-767

These paths predate PR #679 and are unrelated to PR #771's runtime changes.

Acceptance criteria

  1. SQLite remains the canonical committed store.
  2. If either sidecar fails, import or retranscription returns or emits a partial save outcome with the stable meeting ID and failed artifact names.
  3. Clean completion is emitted only after both sidecars are verified or an explicit product policy accepts their absence.
  4. Recovery idempotently regenerates transcripts.json and metadata from committed SQLite rows for the same meeting.
  5. Recovery never reruns ASR and never creates a duplicate meeting.
  6. Tests inject transcript write, metadata write, and rename failures after a successful database commit for both import and retranscription.

References

Source: Zackriya-Solutions/meetily