Initialize query failed to execute after retries: {}\n\nCaus

Error message

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

What it means

The retry-tolerant sibling of the immediate init failure: ThreadSafeConnection retries schema-lock errors up to CONNECTION_INITIALIZE_RETRIES times, sleeping CONNECTION_INITIALIZE_RETRY_DELAY between attempts. If the schema lock is still held after the final attempt, it panics with 'Initialize query failed to execute after retries' plus the last recorded error (crates/sqlez/src/thread_safe_connection.rs:231).

Source

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

                            && 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
        // are from the background thread that can serialize them.
        *connection.write.get_mut() = false;

        connection
    }
}

fn is_schema_lock_error(err: &anyhow::Error) -> bool {
    let message = format!("{err:#}");
    message.contains("database schema is locked") || message.contains("database is locked")
}

View on GitHub (pinned to f4178619ac)

Solutions

Close the other process using the database (check for hung instances with ps) and relaunch.
If it persists, rename the database file so a fresh one is created: mv ~/.config/Zed/db.sqlite ~/.config/Zed/db.sqlite.bak.
On shared/slow storage, ensure only one instance accesses the file at a time.
Check the 'Caused by:' chain to confirm it is a lock error rather than corruption misclassified as retryable.

Example fix

# before: 'Initialize query failed to execute after retries' at startup

# after: stop the other holder, then relaunch
ps aux | grep -i zed   # find the hung instance, kill it
kill <pid>

Defensive patterns

Strategy: retry

Prevention

Close other processes using the database before starting a new one.
Check for hung instances (ps) after crashes; kill them before relaunch.
The built-in retry only covers schema locks — corruption needs the file-rename path.
Avoid sharing one db across instances on network storage.

When it happens

Trigger: Another process holding the SQLite schema lock longer than the retry budget — a concurrent Zed instance migrating the same database, or a previous process still alive (hung, or mid-schema-change) while a new one opens the connection.

Common situations: Two app instances racing on one db file; a hung process from an earlier session; slow storage stretching migration time past the retry window.

Related errors

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