pydantic/monty · error · Error

Invalid display format: '${format}'. Expected 'type-msg' or

Error message

Invalid display format: '${format}'. Expected 'type-msg' or 'msg'

What it means

Thrown by the `display()` method of a Monty error wrapper when its `format` argument is neither the string `'type-msg'` nor `'msg'` (nor omitted, which defaults to `'msg'`). It is a plain developer-facing argument-validation error: the caller passed an unsupported format literal to the formatter, so no exception data is involved. Fix the call site to pass one of the two allowed format strings.

Source

Thrown at crates/monty-js/ts/errors.ts:62

  }

  /** Information about the inner Python exception. */
  get exception(): ExceptionInfo {
    return { typeName: this.typeName, message: this.innerMessage }
  }

  /**
   * Formats the exception: `'type-msg'` for `ExceptionType: message`,
   * `'msg'` (default) for just the message.
   */
  display(format: 'type-msg' | 'msg' = 'msg'): string {
    switch (format) {
      case 'msg':
        return this.innerMessage
      case 'type-msg':
        return this.innerMessage ? `${this.typeName}: ${this.innerMessage}` : this.typeName
      default:
        throw new Error(`Invalid display format: '${format}'. Expected 'type-msg' or 'msg'`)
    }
  }
}

/**
 * Raised when the fed code cannot be parsed. The inner exception is always a
 * `SyntaxError`.
 */
export class MontySyntaxError extends MontyError {
  private readonly tracebackText: string

  constructor(message: string, tracebackText = '') {
    super('SyntaxError', message)
    this.name = 'MontySyntaxError'
    this.tracebackText = tracebackText
  }

  /**

View on GitHub (pinned to adc986b362)

Solutions

  1. Call display('msg') for the bare message or display('type-msg') for 'Type: message'
  2. Validate/whitelist the format value before calling display
  3. Fall back: const text = fmt === 'msg' || fmt === 'type-msg' ? err.display(fmt) : err.display('type-msg')

Example fix

// before
const text = err.display('short');
// after
const text = err.display('type-msg');
Defensive patterns

Strategy: type-guard

Validate before calling

const DISPLAY_FORMATS = ['msg', 'type-msg'];
if (!DISPLAY_FORMATS.includes(fmt)) fmt = 'type-msg';

Type guard

function isDisplayFormat(v) {
  return v === 'msg' || v === 'type-msg';
}

Try / catch

try {
  text = err.display(fmt);
} catch (e) {
  if (e instanceof Error && e.message.includes('Invalid display format')) {
    text = err.display('type-msg');
  } else throw e;
}

Prevention

When it happens

Trigger: Calling error.display('short'), display('full'), or a dynamically computed format string that is not exactly one of the two supported literals.

Common situations: Guessing format names from other logging libraries; user-configurable display options flowing through unchecked; typos like 'type_msg'.

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


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