langfuse/langfuse · error

invalid_request

invalid_request

Error message

params.message (invalid widget request message)

What it means

throwInvalidWidget is the shared 400 invalid_request factory for public dashboard widget requests (getPublicDashboardWidgetViewDeclaration, input normalization/validation). The message is whatever the caller passes — typically an invalid widget type, filter, or field value.

Source

Thrown at web/src/features/widgets/server/public-dashboard-widget-service.ts:45

} from "@/src/features/dashboard/lib/dashboardUiTableToViewMapping";
import {
  MAX_PIVOT_TABLE_DIMENSIONS,
  MAX_PIVOT_TABLE_METRICS,
} from "@/src/features/widgets/utils/pivot-table-utils";

// The widget shape used internally after input normalization: the public
// body with chartConfig and filters fully resolved.
type NormalizedWidgetInput = Omit<
  z.infer<typeof PostUnstableDashboardWidgetResponse>,
  "id" | "createdAt" | "updatedAt"
>;

const throwInvalidWidget = (params: {
  message: string;
  field?: string;
  allowedValues?: string[];
}): never => {
  throw createStructuredPublicApiError({
    httpCode: 400,
    code: "invalid_request",
    message: params.message,
    details:
      params.field || params.allowedValues
        ? {
            field: params.field,
            allowedValues: params.allowedValues,
          }
        : undefined,
  });
};

function resolvePublicWidgetPersistedViewVersion(
  widget: NormalizedWidgetInput,
  persistedMinVersion?: number,
): ViewVersion {
  return resolveDashboardWidgetMinVersion(

View on GitHub (pinned to 59d92c7cf3)

Solutions

1. Read the message/details — it names the invalid field and (when applicable) allowedValues.
2. Use only widget types returned by the dashboard/widget declaration endpoint.
3. After a Langfuse upgrade, clear or migrate persisted widget configs referencing removed types.

Example fix

// before
GET /api/public/dashboard-widgets?type=custom_funnel
// after
GET /api/public/dashboard-widgets?type=traces-timeseries

const WIDGET_TYPES = [/* from declaration endpoint */];
if (!WIDGET_TYPES.includes(widget.type)) throw new Error(`Unknown widget type ${widget.type}`);

const isKnownWidgetType = (t: string): t is WidgetType => WIDGET_TYPES.includes(t as WidgetType);

catch (e) { if (e?.code === "invalid_request" && e.details?.allowedValues) restrictSelectorTo(e.details.allowedValues); }

When it happens

Trigger: Requesting a public dashboard widget whose 'type' is not one of the allowed widget types, or passing invalid filters/pagination in the widget query payload.

Common situations: Frontend deployed ahead of backend (new widget type not yet supported), stale widget config persisted with a removed type, or hand-crafted API calls with wrong enum values.

Understand the failure class

Background: Invalid enum value errors: "Unknown type", "Invalid scope", "must be one of" — when a string is not on the library's allowed list — this error's family across 23 libraries.

Related errors

• Dataset id must not be empty
• Dataset name not valid. ${validation.error.message}
• Trace not found
• Invalid request data
• Invalid input

AI-assisted analysis of langfuse/langfuse@59d92c7cf3 (2026-08-27). Data as JSON: /api/errors/0470f38e3475bf7a. Report an issue: GitHub.