Initialize query failed to execute: {}\n\nCaused by:\n{err:#

Error message

Initialize query failed to execute: {}\n\nCaused by:\n{err:#}

What it means

sqlez's ThreadSafeConnection runs an initialization SQL script each time it opens a SQLite connection (schema setup). It retries only when the error is a schema lock and attempts remain; every other SQLite error panics immediately with the SQL text and the full error chain (crates/sqlez/src/thread_safe_connection.rs:220). The chained 'Caused by:' entries carry the actual SQLite error code, which decides the fix.

Source

Thrown at crates/sqlez/src/thread_safe_connection.rs:220

        if let Some(initialize_query) = connection_initialize_query {
            let mut last_error = None;
            let initialized = (0..CONNECTION_INITIALIZE_RETRIES).any(|attempt| {
                match connection
                    .exec(initialize_query)
                    .and_then(|mut statement| statement())
                {
                    Ok(()) => true,
                    Err(err)
                        if is_schema_lock_error(&err)
                            && attempt + 1 < CONNECTION_INITIALIZE_RETRIES =>
                    {
                        last_error = Some(err);
                        thread::sleep(CONNECTION_INITIALIZE_RETRY_DELAY);
                        false
                    }
                    Err(err) => {
                        panic!(
                            "Initialize query failed to execute: {}\n\nCaused by:\n{err:#}",
                            initialize_query
                        )
                    }
                }
            });

            if !initialized {
                let err = last_error
                    .expect("connection initialization retries should record the last error");
                panic!(
                    "Initialize query failed to execute after retries: {}\n\nCaused by:\n{err:#}",
                    initialize_query
                );
            }
        }

        // Disallow writes on the connection. The only writes allowed for thread safe connections

View on GitHub (pinned to f4178619ac)

Solutions

Read the 'Caused by:' chain in the panic to get the SQLite error code — it selects the right fix below.
For corrupt/IO errors, quit the app and rename the database so it is recreated, e.g. mv ~/.config/Zed/db.sqlite ~/.config/Zed/db.sqlite.bak (path varies by channel/platform).
For permission errors, fix write permission on the config directory; for full disk, free space and relaunch.
If you wrote the initialize query, run it manually with the sqlite3 CLI against a scratch copy to catch SQL errors.

Example fix

# before: startup panics with 'Initialize query failed to execute'

# after: back up the damaged database and relaunch so it is recreated
mv ~/.config/Zed/db.sqlite ~/.config/Zed/db.sqlite.bak

Defensive patterns

Strategy: retry

Prevention

Run one application instance per database file.
Include the db file in backups; it can be renamed and regenerated safely.
Smoke-test migration SQL with the sqlite3 CLI before shipping it in an initialize query.
Ensure the config directory is writable and the disk has space before launch.

When it happens

Trigger: Opening a ThreadSafeConnection whose initialize query fails: SQLITE_CORRUPT (damaged database file), SQLITE_IOERR/SQLITE_FULL (disk failure or full disk), SQLITE_READONLY/permissions on the db file or its directory, a syntax error in the init SQL itself, or a lock error the retry loop does not classify as a schema lock.

Common situations: Zed's db.sqlite corrupted after a crash or kill; disk full; running from an unwritable HOME or read-only mount; a dev experiment shipping a bad migration query in the initialize script.

Related errors

AI-assisted analysis of zed-industries/zed@f4178619ac (2026-08-20). Data as JSON: /api/errors/6df7423990d3088c. Report an issue: GitHub.