langflow-ai/langflow · warning · ValueError

actions capped at {_MAX_ACTIONS} unique entries

Error message

actions capped at {_MAX_ACTIONS} unique entries

What it means

Pydantic validator cap on the /authz/me effective-permissions request: after normalization (strip, lowercase, dedupe) the actions list must not exceed _MAX_ACTIONS unique entries, otherwise ValueError is raised and FastAPI returns HTTP 422.

Source

Thrown at src/backend/base/langflow/api/v1/authz_me.py:112

        """
        if value is None:
            return None
        seen: set[str] = set()
        normalized: list[str] = []
        for raw in value:
            if not isinstance(raw, str):
                # Pydantic field_validators must raise ValueError (not TypeError)
                # to be wrapped into a ValidationError -> HTTP 422 response.
                msg = "actions must be strings"
                raise ValueError(msg)  # noqa: TRY004
            cleaned = raw.strip().lower()
            if not cleaned or cleaned in seen:
                continue
            seen.add(cleaned)
            normalized.append(cleaned)
        if len(normalized) > _MAX_ACTIONS:
            msg = f"actions capped at {_MAX_ACTIONS} unique entries"
            raise ValueError(msg)
        return normalized or None


class EffectivePermissionsResponse(BaseModel):
    """Response: ``{resource_id: [allowed_actions]}``."""

    resource_type: ResourceTypeLiteral
    permissions: dict[UUID, list[str]]


async def _owned_resource_ids(
    *,
    session: AsyncSession,
    resource_type: str,
    resource_ids: list[UUID],
    user_id: UUID,
) -> set[UUID]:
    """Return requested resource IDs owned by ``user_id``."""

View on GitHub (pinned to 976ec789d2)

Solutions

  1. Request only the actions the UI actually gates on (typically read/write/execute/delete)
  2. Deduplicate and cap client-side before sending
  3. Omit actions to fall back to _DEFAULT_ACTIONS
  4. If you legitimately need more, batch requests per resource group rather than raising the server cap

Example fix

// before
const actions = allPermissionSlugs; // hundreds of entries

// after
const actions = [...new Set(needed)].slice(0, 20); // e.g. cap at known limit
Defensive patterns

Strategy: validation

Validate before calling

const MAX_ACTIONS = 32; // keep in sync with server _MAX_ACTIONS
const actions = [...new Set(raw.map(a => a.trim().toLowerCase()))].slice(0, MAX_ACTIONS);

Prevention

When it happens

Trigger: POST with more than _MAX_ACTIONS distinct action strings after cleaning — e.g. programmatically enumerating every resource:action permutation from the permission catalog instead of the handful of UI-relevant actions.

Common situations: Frontends that build the actions list from a full permission-slug catalog (which grows as resources are added) and eventually cross the cap, or code that concatenates multiple action lists without dedupe awareness (duplicates are fine, unique count is what's capped).

Related errors


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