tinyhumansai/openhuman · error

rebuilt whatsapp_data db still fails integrity_check at {}

Error message

rebuilt whatsapp_data db still fails integrity_check at {}

What it means

whatsapp_data's corruption recovery already ran: bad files were quarantined and an empty schema rebuilt — yet the follow-up integrity_check on the rebuilt database still reports corruption (Ok(false)). This means the storage location or the rebuild path itself is unhealthy, not merely one damaged input file; the error includes the db path.

Source

Thrown at app/src-tauri/src/whatsapp_data/store.rs:375

        //    check itself can't run — we MUST surface `Err`, otherwise the
        //    latch resets, re-arming Sentry to page on the next scan tick and
        //    breaking the report-once-per-episode guarantee this recovery
        //    exists to protect.
        match self.integrity_check_ok() {
            Ok(true) => {
                log::warn!(
                    "[whatsapp_data] corruption recovery complete: quarantined {quarantined} file(s), \
                     rebuilt empty schema, integrity_check=ok at {}",
                    self.db_path.display()
                );
                Ok(true)
            }
            Ok(false) => {
                log::error!(
                    "[whatsapp_data] rebuilt DB still fails integrity_check at {}",
                    self.db_path.display()
                );
                Err(anyhow::anyhow!(
                    "rebuilt whatsapp_data db still fails integrity_check at {}",
                    self.db_path.display()
                ))
            }
            Err(e) => Err(e.context("integrity_check after rebuild could not run")),
        }
    }

    /// Run `PRAGMA quick_check(1)` on a fresh, short-lived connection. Returns
    /// `Ok(true)` when the structural scan reports `"ok"`, `Ok(false)` on any
    /// reported corruption, and `Err` when the check itself can't run (file
    /// unopenable / header unreadable — itself a corruption signal the caller
    /// treats as malformed).
    fn quick_check_ok(&self) -> Result<bool> {
        let conn = Connection::open(&self.db_path)
            .with_context(|| format!("open for quick_check: {}", self.db_path.display()))?;
        let _ = conn.busy_timeout(BUSY_TIMEOUT);
        let result: String = conn

View on GitHub (pinned to a221052e0d)

Solutions

1. Stop the app and delete the whatsapp_data db directory entirely — it is a cache re-derived from WhatsApp data — then relaunch so it is created fresh
2. Exclude the db directory from sync clients and AV scans, or move the workspace off synced/removable storage
3. If corruption recurs across unrelated files, check disk health (SMART) — this is then a hardware symptom, not an app bug

Example fix

# before — log loops: rebuilt whatsapp_data db still fails integrity_check at <path>
# after — nuke the cache db and let the app rebuild from scratch
 rm -rf '<path-from-the-error-message>'/*.db*   # path is printed in the error
# then relaunch the app

// probe the store before scheduling ingestion
if !store.quick_check().unwrap_or(false) {
    // one recovery attempt is the design; a second failure means the location is bad
    log::error!("[whatsapp_data] corruption detected — recovery will run once");
}

match store.recover_if_corrupt() {
    Ok(true) => log::info!("[whatsapp_data] recovered"),
    Ok(false) => {}
    Err(e) if e.to_string().contains("still fails integrity_check") => {
        log::error!("[whatsapp_data] quarantine loop — deleting db dir for full rebuild");
        store.delete_db_dir()?;  // cache is re-derivable from WhatsApp data
    }
    Err(e) => return Err(e),
}

When it happens

Trigger: Disk-level corruption at the whatsapp_data db path so even the fresh rebuild comes back corrupt; an external process (cloud-sync client, antivirus) rewriting the new file as it is created; the db living on unreliable removable/network storage.

Common situations: Workspace under Dropbox/OneDrive/iCloud sync mutating SQLite files; failing SSD sectors; recovery loops where each quarantine+rebuild cycle corrupts again.

Related errors

• open chat.db failed ({}). Grant Full Disk Access to OpenHuma
• open chat.db failed for full-day read ({})
• whatsapp_data write lock poisoned: {e}
• learning_update_facet: {e:#}
• learning_update_facet: upsert failed: {e:#}

AI-assisted analysis of tinyhumansai/openhuman@a221052e0d (2026-08-16). Data as JSON: /api/errors/836d52f306f36322. Report an issue: GitHub.