nocobase/nocobase · error · FlowSurfaceBadRequestError

flowSurfaces field type '${requestedType}' is not a supporte

Error message

flowSurfaces field type '${requestedType}' is not a supported public capability

What it means

resolveStandaloneFieldUse accepts only three public standalone field types: jsColumn, jsItem, and divider. Any other requestedType string reaches the final throw. This is a deliberate allowlist so unsupported/internal models cannot be instantiated through the public flowSurfaces apply API.

Source

Thrown at packages/plugins/@nocobase/plugin-flow-engine/src/server/flow-surfaces/catalog.ts:3164

    }
    return 'JSColumnModel';
  }
  if (requestedType === 'jsItem') {
    if (normalizeFieldContainerUse(input.containerUse) !== 'form') {
      throw new FlowSurfaceBadRequestError(`flowSurfaces field type 'jsItem' is only allowed under form containers`);
    }
    return 'JSItemModel';
  }
  if (requestedType === 'divider') {
    const containerKind = normalizeFieldContainerUse(input.containerUse);
    if (containerKind !== 'form' && containerKind !== 'details') {
      throw new FlowSurfaceBadRequestError(
        `flowSurfaces field type 'divider' is only allowed under form or details containers`,
      );
    }
    return 'DividerItemModel';
  }
  throw new FlowSurfaceBadRequestError(
    `flowSurfaces field type '${requestedType}' is not a supported public capability`,
  );
}

export function resolveSupportedFieldCapability(input: {
  containerUse: string;
  field?: any;
  requestedFieldUse?: string;
  requestedFieldUseMode?: 'fieldUse' | 'fieldType';
  requestedWrapperUse?: string;
  allowUnresolvedFieldUse?: boolean;
  requestedRenderer?: string;
  requestedType?: string;
  enabledPackages?: ReadonlySet<string>;
  dataSourceKey?: string;
  getCollection?: (dataSourceKey: string, collectionName: string) => any;
}) {
  const requestedRenderer =

View on GitHub (pinned to fa42722fef)

Solutions

  1. Use one of the supported requestedType values: 'jsColumn', 'jsItem', or 'divider'
  2. Drop requestedType and rely on the normal field-interface-based inference for ordinary fields
  3. Check the plugin version's documented public field capability list — internal types may have been intentionally excluded

Example fix

// before
{ requestedType: 'customColumn', containerUse: 'table' }
// after
{ requestedType: 'jsColumn', containerUse: 'table' }
Defensive patterns

Strategy: validation

Validate before calling

const PUBLIC_STANDALONE_TYPES = ['jsColumn', 'jsItem', 'divider'];
if (requestedType && !PUBLIC_STANDALONE_TYPES.includes(requestedType)) {
  throw new Error(`requestedType must be one of ${PUBLIC_STANDALONE_TYPES.join(', ')}`);
}

Type guard

function isPublicStandaloneFieldType(v) {
  return v === 'jsColumn' || v === 'jsItem' || v === 'divider';
}

Try / catch

try {
  resolveFieldCapability({ requestedType, containerUse });
} catch (err) {
  if (err?.code === 'FLOW_SURFACE_BAD_REQUEST' && /not a supported public capability/.test(err.message)) {
    // drop requestedType to use interface-based inference
  } else throw err;
}

Prevention

When it happens

Trigger: Passing requestedType values like 'field', 'column', 'js', or an internal model name to the standalone field capability resolver (via requestedFieldUseMode 'fieldType').

Common situations: Migrating specs from internal APIs to the public capability surface and using internal type names; typos (e.g. 'jsColum'); assuming more field types are public than documented.

Related errors


AI-assisted analysis of nocobase/nocobase@fa42722fef (2026-09-01). Data as JSON: /api/errors/4ffc8285ff8516d3. Report an issue: GitHub.