pydantic/monty · error · RangeError

unknown typeCheckFormat '${format}', expected one of: ${Obje

Error message

unknown typeCheckFormat '${format}', expected one of: ${Object.keys(TYPE_CHECK_FORMATS).join(', ')}

What it means

`typeCheckFormat` was given a value that is not one of the recognized format names. The library looks the format up in a `TYPE_CHECK_FORMATS` lookup table using `Object.hasOwn` (so inherited names like `'toString'` are rejected, not passed to the wire encoder) and throws `RangeError` listing the valid keys when the value is absent.

Source

Thrown at crates/monty-js/ts/options.ts:46

  json: 4,
  jsonlines: 5,
  rdjson: 6,
  pylint: 7,
  gitlab: 8,
  github: 9,
}

/**
 * Encodes a {@link TypeCheckFormat} to its wire number, throwing on an unknown name.
 *
 * The own-property check matters: JavaScript callers are not bound by the
 * type, and a plain lookup would find inherited names like `'toString'` and
 * hand a `Function` to the wire encoder instead of rejecting it here.
 */
export function encodeTypeCheckFormat(format: TypeCheckFormat): number {
  const encoded = Object.hasOwn(TYPE_CHECK_FORMATS, format) ? TYPE_CHECK_FORMATS[format] : undefined
  if (encoded === undefined) {
    throw new RangeError(
      `unknown typeCheckFormat '${format}', expected one of: ${Object.keys(TYPE_CHECK_FORMATS).join(', ')}`,
    )
  }
  return encoded
}

/**
 * The `assertMessageAnnotations` checkout option: `true`/`false`, or an
 * integer customizing the per-operand repr truncation length (in bytes,
 * default 120) of introspected `assert` failure messages.
 */
export type AssertMessageAnnotations = boolean | number

/**
 * Normalizes {@link AssertMessageAnnotations} to the wire encoding of
 * `Configure.assert_message_annotations`: `undefined`/`true` → absent (the
 * child's default, a 120-byte truncation), `false` → `0` (off), an integer →
 * a custom truncation length. Throws `RangeError` for numbers the wire's

View on GitHub (pinned to adc986b362)

Solutions

1. Use one of the exact names listed in the error message (the current keys of TYPE_CHECK_FORMATS)
2. If the value comes from user config, validate/normalize it against the allowed keys before calling checkout
3. Omit the option entirely to use the library default

Example fix

// before
const session = await pool.checkout({ typeCheck: true, typeCheckFormat: 'text' })
// after
const session = await pool.checkout({ typeCheck: true, typeCheckFormat: 'pyright' })

const VALID = ['pyright', 'off'] // see error message for current keys
if (!VALID.includes(options.typeCheckFormat)) throw new Error(`bad typeCheckFormat: ${options.typeCheckFormat}`)

function isTypeCheckFormat(v: unknown): v is TypeCheckFormat {
  return typeof v === 'string' && Object.hasOwn(TYPE_CHECK_FORMATS, v)
}

try {
  session = await pool.checkout(opts)
} catch (e) {
  if (e instanceof RangeError && e.message.startsWith("unknown typeCheckFormat")) {
    opts.typeCheckFormat = undefined // fall back to default
    session = await pool.checkout(opts)
  } else throw e
}

When it happens

Trigger: Passing `typeCheckFormat: 'text'`, a misspelled name like `'tyepcheck'`, or a non-string value (e.g. `true`) in `CheckoutOptions` during `pool.checkout(...)`.

Common situations: Copying option names from the Python binding or another library, typo after renaming a constant, hand-editing config where the format is stored as a string.

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

• assertMessageAnnotations must be a boolean or an integer bet
• (dynamic: diagnostics from the type checker)
• ClassInstance expects an object instance
• notCallableMessage(method)
• ClassInstance expects an instance of a class, not a null-pro

AI-assisted analysis of pydantic/monty@adc986b362 (2026-09-13). Data as JSON: /api/errors/d4d3d06d16ae67c9. Report an issue: GitHub.