langflow-ai/langflow · error · HTTPException

Flow is not accessible

Error message

Flow is not accessible

What it means

After the flow is confirmed public, verify_public_flow_and_get_user() resolves the flow's owner via get_user_by_flow_id_or_endpoint_name(). Any exception from that lookup is logged (logger.aexception) and converted into 403 'Flow is not accessible'. This guards against partial state — a public flow row whose user_id points at a deleted/missing user — so anonymous callers never proceed without an owner context.

Source

Thrown at src/backend/base/langflow/api/utils/flow_utils.py:280

    if authenticated_user_id is not None:
        identifier = str(authenticated_user_id)
        principal_type: Literal["user", "client"] = "user"
    else:
        if client_id is None:
            raise HTTPException(status_code=400, detail="No client_id cookie found")
        identifier = client_id
        principal_type = "client"
    new_flow_id = compute_virtual_flow_id(identifier, flow_id, principal_type=principal_type)

    # Get the user associated with the flow
    try:
        from langflow.helpers.user import get_user_by_flow_id_or_endpoint_name

        user = await get_user_by_flow_id_or_endpoint_name(str(flow_id))

    except Exception as exc:
        await logger.aexception("Error getting user for public flow %s", flow_id)
        raise HTTPException(status_code=403, detail="Flow is not accessible") from exc

    if not user:
        raise HTTPException(status_code=403, detail="Flow is not accessible")

    return user, new_flow_id

View on GitHub (pinned to 976ec789d2)

Solutions

1. Check the server logs for the chained exception right after 'Error getting user for public flow' — it names the real DB failure.
2. Verify the flow's user_id in the DB points at an existing user row; if the owner was deleted, either delete the (now orphaned) flow or update its user_id to a valid owner.
3. If the underlying cause is DB connectivity, fix that (pool size, DB up) and retry the request.
4. If this reproduces consistently, repair ownership via a migration/script rather than re-sharing the flow.

Example fix

# before: orphaned flow
-- flow.user_id -> users.id that no longer exists

# after
UPDATE flow SET user_id = '<valid-admin-uuid>' WHERE id = '<flow_id>';
-- or delete the orphaned flow

try:
    user, vfid = await verify_public_flow_and_get_user(flow_id, client_id)
except HTTPException as e:
    if e.status_code == 403 and e.detail == 'Flow is not accessible':
        # check server log for 'Error getting user for public flow' — the chained exc is the real cause
        log_error(f'owner lookup failed for flow {flow_id}'); raise

When it happens

Trigger: The flow row exists and is PUBLIC but its user_id references a deleted user (cascade gaps after user deletion), or the DB lookup itself throws (connection drop, corrupted row, wrong database). The exception is chained (`from exc`), and the server log contains the underlying traceback under 'Error getting user for public flow {flow_id}'.

Common situations: User accounts deleted without cascade-deleting or re-assigning their flows; restoring a database dump where user rows are missing; transient DB failures during high load; multi-tenant setups where the flow was migrated between workspaces without its owner.

Related errors

• Flow is not public
• Flow is not public
• Could not create default folder.
• Flow creation failed.
• response.model_dump()

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