langflow-ai/langflow · warning · HTTPException

Cannot cancel job with status '{job_status}'

Error message

Cannot cancel job with status '{job_status}'

What it means

400 from POST /api/v1/knowledge_bases/{kb_name}/cancel. A latest job was found, but its status is terminal — 'completed', 'failed', 'cancelled', or 'timed_out' — so there is nothing to cancel. The endpoint only cancels jobs still in a live state (running/pending). The message echoes the actual status so callers can distinguish each case.

Source

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

        metadata = KBAnalysisHelper.get_metadata(kb_path, fast=True)
        asset_id = await _resolve_kb_asset_id(
            kb_name=kb_name,
            current_user=current_user,
            metadata=metadata,
        )

        # Fetch the latest ingestion job for this KB
        latest_jobs = await job_service.get_latest_jobs_by_asset_ids([asset_id])

        if asset_id not in latest_jobs:
            raise HTTPException(status_code=404, detail=f"No ingestion job found for the knowledge base {kb_name}")

        job = latest_jobs[asset_id]
        job_status = job.status.value if hasattr(job.status, "value") else str(job.status)

        # Check if job is already completed or failed
        if job_status in ["completed", "failed", "cancelled", "timed_out"]:
            raise HTTPException(status_code=400, detail=f"Cannot cancel job with status '{job_status}'")

        revoked = await task_service.revoke_task(job.job_id)
        # Update status immediately so background task can see it
        await job_service.update_job_status(job.job_id, JobStatus.CANCELLED)

        # Clean up any partially ingested chunks from this job. Forward
        # the KB's configured backend + user_id so non-Chroma KBs
        # (Mongo/Astra/Postgres) actually find their variable-backed
        # credentials and delete against the right store — otherwise
        # cleanup silently falls back to Chroma and remote chunks
        # written before the cancel stick around.
        kb_record = _kb_guard.record or await knowledge_base_service.get_by_user_and_name(
            _kb_guard.owner_user.id, kb_name
        )
        backend_type_value = (
            kb_record.backend_type if kb_record and kb_record.backend_type else BackendType.CHROMA.value
        )
        backend_config = (kb_record.backend_config or {}) if kb_record is not None else {}

View on GitHub (pinned to 976ec789d2)

Solutions

  1. Re-fetch the job/run status before cancelling and skip if terminal
  2. Treat 'completed'/'cancelled' responses as success — the end state you wanted is already reached
  3. Debounce/disable the Cancel button once a cancel request is in flight

Example fix

// before
await api.post(`/api/v1/knowledge_bases/${kbName}/cancel`);

// after
const jobs = await api.get(`/api/v1/knowledge_bases/${kbName}/runs`);
const latest = jobs.data.results?.[0];
if (["completed", "failed", "cancelled", "timed_out"].includes(latest?.status)) {
  console.log(`Nothing to cancel, job already ${latest.status}`);
} else {
  await api.post(`/api/v1/knowledge_bases/${kbName}/cancel`);
}
Defensive patterns

Strategy: type-guard

Validate before calling

TERMINAL = {"completed", "failed", "cancelled", "timed_out"}
latest = (await client.get(f"/api/v1/knowledge_bases/{kb_name}/runs")).json()["results"][0]
if latest["status"] not in TERMINAL:
    await client.post(f"/api/v1/knowledge_bases/{kb_name}/cancel")

Type guard

const TERMINAL = new Set(["completed", "failed", "cancelled", "timed_out"]);
function isCancellable(status: string): boolean {
  return !TERMINAL.has(status);
}

Try / catch

try:
    await client.post(f"/api/v1/knowledge_bases/{kb_name}/cancel")
except httpx.HTTPStatusError as e:
    if e.response.status_code == 400 and "Cannot cancel" in e.response.json()["detail"]:
        return  # already terminal — goal state reached
    raise

Prevention

When it happens

Trigger: Cancelling after ingestion already finished; double-clicking Cancel (second request sees status 'cancelled'); cancelling a job that timed out on its own.

Common situations: Race between the UI's Cancel button and a small ingestion finishing first; stale UI showing an in-progress badge for a job that already completed; retry logic re-sending a cancel.

Related errors


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