langflow-ai/langflow · error · HTTPException

Error deleting knowledge base.

Error message

Error deleting knowledge base.

What it means

500 from DELETE /api/v1/knowledge_bases/{kb_name} when deleting the database row fails. The handler deliberately deletes the DB row first (so a partially-deleted KB never lingers), and if knowledge_base_service.delete_by_user_and_name raises, it logs 'KB DB delete failed for <kb>: <exc>' and returns this 500. Storage cleanup is NOT attempted in this path — the failure happened before it.

Source

Thrown at src/backend/base/langflow/api/v1/knowledge_bases.py:2100

        remote_warning = await _delete_remote_backend_collection(
            kb_name=kb_name,
            kb_path=kb_path,
            current_user=kb_owner,
        )

        # Delete the DB row first, then attempt to clear the on-disk dir.
        # Rationale: when Chroma still holds a SQLite lock (most common on
        # Windows) physical removal can fail, but the user's intent was to
        # remove the KB.  By dropping the DB row first the row never lingers
        # past a partial cleanup, and KBStorageHelper.delete_storage() drops
        # a sentinel inside any dir it could not remove so the listing layer
        # treats it as gone until the next restart fully reaps it.
        try:
            await knowledge_base_service.delete_by_user_and_name(_kb_guard.owner_user.id, kb_name)
        except Exception as exc:
            await logger.aerror("KB DB delete failed for %s: %s", kb_name, exc)
            raise HTTPException(status_code=500, detail="Error deleting knowledge base.") from exc

        storage_warning: str | None = None
        if not KBStorageHelper.delete_storage(kb_path, kb_name):
            # Both physical removal AND the sentinel write failed.  This is
            # rare (would require the dir itself being unwritable) but we
            # still return 200 because the DB row is gone -- the user no
            # longer sees the KB.  A warning surfaces so operators know the
            # bytes are still on disk and want a follow-up cleanup.
            storage_warning = (
                f"Knowledge base '{kb_name}' was removed from the database but its on-disk "
                "files could not be cleaned up. The KB will not reappear in the UI; the bytes "
                "will be removed on the next server restart."
            )
            await logger.awarning(storage_warning)

    except HTTPException:
        raise
    except Exception as e:

View on GitHub (pinned to 976ec789d2)

Solutions

  1. Check the server log for 'KB DB delete failed for ...' — the exception identifies the DB-level cause
  2. Retry after any concurrent ingestion/cancel on the KB finishes (locks clear)
  3. Verify DB connectivity and connection-pool health
  4. If persistent, inspect for FK constraints or orphaned rows blocking the delete
Defensive patterns

Strategy: retry

Try / catch

for attempt in range(3):
    try:
        await client.delete(f"/api/v1/knowledge_bases/{kb_name}")
        break
    except httpx.HTTPStatusError as e:
        if e.response.status_code == 500 and attempt < 2:
            await asyncio.sleep(2 ** attempt)  # DB lock likely transient
            continue
        raise

Prevention

When it happens

Trigger: DELETE /{kb_name} while the database is unavailable, locked, or the delete statement violates a constraint (e.g. dependent rows); transient DB connection drops mid-request.

Common situations: Another process holding a DB lock (long-running ingestion writing run rows), DB connection pool exhausted, network blip to a remote Postgres/MySQL.

Related errors

AI-assisted analysis of langflow-ai/langflow@976ec789d2 (2026-08-14). Data as JSON: /api/errors/3f3063ebca11dcc2. Report an issue: GitHub.