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
- Check the `{e:?}` chain for the underlying cause (connectivity vs. schema).
- Run pending database migrations.
- Retry the deletion — deletes are idempotent, so a retry after the transient issue is safe.
- 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
- Retry deletes — idempotent and safe
- Verify migrations ran before workspace cleanup tooling
- Avoid deleting conversations during DB maintenance windows
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
- Database read failed: {e:?}
- Database write failed: {e:?}
- You can only delete forked workspaces where the workspace id
- Unsupported database type:${dbType}
- Unsupported database type
AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03).
Data as JSON: /api/errors/c887d5ff9167941d.
Report an issue: GitHub.