windmill-labs/windmill · error

Database delete failed: {e:?}

Error message

Database delete failed: {e:?}

What it means

OSS agent memory deleter: `delete_conversation_memory` wraps failures of `memory_common::delete_conversation_from_db`, which removes all stored messages for a conversation. A failure leaves stale conversation memory in the database and the deletion caller surfaces an error.

Source

Thrown at backend/windmill-worker/src/memory_oss.rs:53

        return Ok(());
    }

    memory_common::write_to_db(db, workspace_id, conversation_id, step_id, messages)
        .await
        .map_err(|e| anyhow::anyhow!("Database write failed: {e:?}"))
}

/// Delete all memory for a conversation from storage
/// In OSS: always deletes from database
#[cfg(not(all(feature = "private", feature = "enterprise")))]
pub async fn delete_conversation_memory(
    db: &DB,
    workspace_id: &str,
    conversation_id: Uuid,
) -> anyhow::Result<()> {
    memory_common::delete_conversation_from_db(db, workspace_id, conversation_id)
        .await
        .map_err(|e| anyhow::anyhow!("Database delete failed: {e:?}"))
}

View on GitHub (pinned to e474e8803c)

Solutions

  1. Check the `{e:?}` chain for the underlying cause (connectivity vs. schema).
  2. Run pending database migrations.
  3. Retry the deletion — deletes are idempotent, so a retry after the transient issue is safe.
  4. If rows persist, delete them manually via SQL for the offending conversation_id.
Defensive patterns

Strategy: retry

Validate before calling

psql "$DATABASE_URL" -c 'select 1 from agent_memory limit 1' || echo 'migrate first'

Try / catch

// deletes are idempotent: retry with backoff
for attempt in 0..3 {
    match delete_conversation_memory(&db, w_id, conv_id).await {
        Ok(()) => break,
        Err(e) if attempt < 2 => tokio::time::sleep(Duration::from_secs(2)).await,
        Err(e) => return Err(e),
    }
}

Prevention

When it happens

Trigger: Calling `delete_conversation_memory(db, workspace_id, conversation_id)` when the DB delete fails — connection drop, missing table (unmigrated DB), or foreign-key restrictions if related rows reference memory entries.

Common situations: Deleting a conversation right as Postgres restarts; OSS instance without the memory migrations; workspace cleanup tooling racing a concurrent write to the same conversation.

Related errors


AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03). Data as JSON: /api/errors/c887d5ff9167941d. Report an issue: GitHub.