What causes "Failed to reload bundle" in langflow-ai/langflow?

Check the aerror log line 'Unexpected error starting MCP Composer ... rolling back auth settings' for the underlying exception.

langflow-ai/langflow · error · Error

Failed to reload bundle

Error message

Failed to reload bundle

What it means

500 raised inside the PATCH handler when starting MCP Composer for OAuth throws an unexpected (non-MCPComposerError) exception. The handler deliberately rolls back project.auth_settings to the pre-request value before failing, so the DB stays consistent, and echoes the raw exception text.

Source

Thrown at src/frontend/src/controllers/API/queries/extensions/use-reload-bundle.ts:85

        typeof detail === "object" &&
        (detail as ReloadInProgressDetail).code === "reload-in-progress"
      ) {
        const inProgress = detail as ReloadInProgressDetail;
        throw new Error(`reload-in-progress: ${inProgress.message}`);
      }

      // 422 carries the full ReloadResult in detail.result so structural
      // failures keep the same body shape as a 200 -- the caller's
      // onSuccess handler renders the typed errors inline via the
      // existing ok=false branch.
      if (status === 422 && detail && typeof detail === "object") {
        const result = (detail as { result?: ReloadBundleResponse }).result;
        if (result && typeof result === "object") {
          return result;
        }
      }

      throw new Error(
        extractApiErrorMessage(
          error as Parameters<typeof extractApiErrorMessage>[0],
          "Failed to reload bundle",
        ),
      );
    }
  }

  const mutation: UseMutationResult<
    ReloadBundleResponse,
    Error,
    ReloadBundleVariables
  > = mutate(["useReloadBundle"], reloadBundle, options);

  return mutation;
};

View on GitHub (pinned to 976ec789d2)

Solutions

Check the aerror log line 'Unexpected error starting MCP Composer ... rolling back auth settings' for the underlying exception.
Verify 'uvx --version' works in the Langflow runtime environment and that the mcp-composer version pin (settings.mcp_composer_version) resolves.
Ensure the composer host/port in auth settings is free and reachable.
Retry the PATCH after fixing the environment — the rollback means no state cleanup is needed.

Defensive patterns

Strategy: try-catch

Validate before calling

import shutil
if shutil.which("uvx") is None:
    raise EnvironmentError("uvx not on PATH; MCP Composer cannot start")

Try / catch

try:
    await client.patch(project_url, json={"auth_type": "oauth", ...})
except httpx.HTTPStatusError as e:
    if e.response.status_code == 500:
        detail = e.response.json().get("detail", "")
        # auth settings were rolled back server-side; safe to fix env and retry

Prevention

Verify uvx and the pinned mcp-composer version work before enabling OAuth on projects.
Reserve a known-free host/port for the composer.
Remember the rollback: after this 500 the previous auth settings are still active, so retrying is idempotent.

When it happens

Trigger: PATCH /api/v1/mcp/projects/{project_id} with auth_type='oauth' while mcp_composer_enabled=True, and get_or_start_mcp_composer raises e.g. a subprocess spawn error (uvx missing), port allocation failure, or an httpx connection error.

Common situations: uv not installed / uvx not on PATH in the container; composer port already in use by a zombie process; first-run image missing the mcp-composer package; OAuth host/port misconfigured.

Related errors

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