{"record":{"id":"42bf879cd7b0dc24","repo":"Zackriya-Solutions/meetily","slug":"failed-to-commit-transaction-42bf87","errorCode":null,"errorMessage":"Failed to commit transaction: {}","messagePattern":"Failed to commit transaction: (.+?)","errorType":"exception","errorClass":"anyhow::Error","httpStatus":null,"severity":"error","filePath":"frontend/src-tauri/src/audio/retranscription.rs","lineNumber":460,"sourceCode":"    for segment in &segments {\n        sqlx::query(\n            \"INSERT INTO transcripts (id, meeting_id, transcript, timestamp, audio_start_time, audio_end_time, duration)\n             VALUES (?, ?, ?, ?, ?, ?, ?)\"\n        )\n        .bind(&segment.id)\n        .bind(&meeting_id)\n        .bind(&segment.text)\n        .bind(&segment.timestamp)\n        .bind(segment.audio_start_time)\n        .bind(segment.audio_end_time)\n        .bind(segment.duration)\n        .execute(&mut *tx)\n        .await\n        .map_err(|e| anyhow!(\"Failed to insert transcript: {}\", e))?;\n    }\n\n    tx.commit().await\n        .map_err(|e| anyhow!(\"Failed to commit transaction: {}\", e))?;\n\n    info!(\n        \"Updated {} transcripts for meeting {} in transaction\",\n        segments.len(),\n        meeting_id\n    );\n\n    // Write updated transcripts.json and metadata.json to the meeting folder\n    emit_progress(&app, &meeting_id, \"saving\", 90, \"Writing transcript files...\");\n\n    if let Err(e) = write_transcripts_json(&folder_path, &segments) {\n        warn!(\"Failed to write transcripts.json: {}\", e);\n    }\n\n    // Find audio filename for metadata\n    let audio_filename = audio_path\n        .file_name()\n        .and_then(|n| n.to_str())","sourceCodeStart":442,"sourceCodeEnd":478,"githubUrl":"https://github.com/Zackriya-Solutions/meetily/blob/0281737d87d26352fb0adc78c8c0975f691b23d1/frontend/src-tauri/src/audio/retranscription.rs#L442-L478","documentation":"tx.commit() failed, so the delete+insert work rolls back and the meeting keeps its previous transcripts. On SQLite, COMMIT is where the write lock is actually exercised, so 'database is locked' (lost lock mid-transaction), disk-full while writing the journal/WAL, or the connection dying are the usual inner causes.","triggerScenarios":"Another process steals the SQLite write lock between the last INSERT and COMMIT; the disk fills during a long transaction spanning hundreds of inserted segments; the DB file is deleted or the drive unmounted mid-save.","commonSituations":"Long meetings produce many segments, widening the lock window; machines with low disk space; another app instance writing at the same moment.","solutions":["Check free disk space first - COMMIT fails hard when the journal cannot be written.","Read the inner error: lock-related messages mean retrying after the competing writer exits usually succeeds.","Shorten the transaction: build all rows first, then execute delete+inserts in one tight burst.","Enable WAL mode and busy_timeout to make commit-time lock loss rare."],"exampleFix":null,"handlingStrategy":"retry","validationCode":null,"typeGuard":null,"tryCatchPattern":"// Retry commit once for lock-style failures; propagate disk errors\nmatch tx.commit().await {\n    Ok(_) => {}\n    Err(e) if e.to_string().contains(\"locked\") || e.to_string().contains(\"busy\") => {\n        // rebuild and retry transaction when idle\n    }\n    Err(e) => return Err(anyhow!(\"Failed to commit transaction: {e}\")),\n}","preventionTips":["Check free disk space before long batch jobs - COMMIT needs journal space.","Minimize the transaction window: prepare rows first, write in one tight burst.","Use WAL mode so readers do not block the committing writer."],"tags":["sqlx","sqlite","transaction","commit","disk-full"],"backgroundTag":"database-transaction-commit-failed","analyzedSha":"0281737d87d26352fb0adc78c8c0975f691b23d1","analyzedAt":"2026-08-16T20:57:52.567Z","schemaVersion":2},"datasetVersion":"2026-08-16T23:17:17.608Z"}