payloadcms/payload · error · TypeError

${typeName} cannot represent value: ${print(ast)}

Error message

${typeName} cannot represent value: ${print(ast)}

What it means

The default branch of `parseLiteral` in the vendored GraphQL JSON scalar. It throws when the AST node passed as a literal argument is a kind the parser does not explicitly handle (the handled kinds are STRING, BOOLEAN, FLOAT, INT, LIST, NULL, OBJECT, VARIABLE, and ENUM implicitly missing). Any other AST kind triggers this generic 'cannot represent value' error with the printed AST. It is a parser-completeness guard, not a normal validation path.

Source

Thrown at packages/graphql/src/packages/graphql-type-json/index.ts:42

function parseLiteral(typeName, ast, variables) {
  switch (ast.kind) {
    case Kind.BOOLEAN:
    case Kind.STRING:
      return ast.value
    case Kind.FLOAT:
    case Kind.INT:
      return parseFloat(ast.value)
    case Kind.LIST:
      return ast.values.map((n) => parseLiteral(typeName, n, variables))
    case Kind.NULL:
      return null
    case Kind.OBJECT:
      return parseObject(typeName, ast, variables)
    case Kind.VARIABLE:
      return variables ? variables[ast.name.value] : undefined
    default:
      throw new TypeError(`${typeName} cannot represent value: ${print(ast)}`)
  }
}

// This named export is intended for users of CommonJS. Users of ES modules
//  should instead use the default export.
export const GraphQLJSON = new GraphQLScalarType({
  name: 'JSON',
  description:
    'The `JSON` scalar type represents JSON values as specified by [ECMA-404](http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf).',
  parseLiteral: (ast, variables) => parseLiteral('JSON', ast, variables),
  parseValue: identity,
  serialize: identity,
  specifiedByURL: 'http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf',
})

export const GraphQLJSONObject = new GraphQLScalarType({
  name: 'JSONObject',
  description:

View on GitHub (pinned to 00c58b35c0)

Solutions

  1. Pass the JSON value as a `$variable` rather than an inline literal — variables route through `parseValue` (identity), bypassing `parseLiteral`.
  2. Ensure the inline literal is one of: string, number, boolean, null, array, or object.
  3. Upgrade the vendored graphql-type-json copy to a version whose `parseLiteral` covers the AST kind in use.

Example fix

// before — inline unusual literal
mutation { set(meta: <weird>) { id } }

// after — use a variable
mutation SetMeta($meta: JSON) { set(meta: $meta) { id } }
Defensive patterns

Strategy: try-catch

Validate before calling

const ALLOWED = ['string','boolean','float','int','list','null','object','variable']
// Prefer variables over inline literals for JSON scalar arguments:
client.request(query, { meta: jsonValue })

Try / catch

try {
  await client.request(mutation, { meta: jsonValue }) // use a variable
} catch (e) {
  if (e instanceof TypeError && /cannot represent value/.test(e.message)) {
    // switch the argument from an inline literal to a $variable
  }
  throw e
}

Prevention

When it happens

Trigger: Sending a GraphQL literal of an unexpected/unsupported kind as a `JSON` argument directly inline in the query (rare — usually means a custom AST kind or a malformed/generated query). More commonly hit when a query-building library emits an unusual node type for a `JSON` argument.

Common situations: Custom GraphQL clients or codegen producing non-standard AST; using the scalar with a GraphQL server version whose `Kind` enum includes types this vendored parser predates; malformed hand-crafted queries.

Related errors


AI-assisted analysis of payloadcms/payload@00c58b35c0 (2026-08-12). Data as JSON: /api/errors/c48a6a04d4bb23bc. Report an issue: GitHub.