pydantic/monty · error · MontyTypingError

(dynamic: diagnostics from the type checker)

Error message

(dynamic: diagnostics from the type checker)

What it means

The worker's type checker rejected the code before execution; the session throws `MontyTypingError` carrying the checker's diagnostics (messages, file/line info from the turn). This is a per-turn, dynamic error — the diagnostics text comes from the type checker, not a fixed string.

Source

Thrown at crates/monty-js/ts/session.ts:217

    const answerer = new TurnAnswerer(this.native, this.instances, options.externalLookup, options.os)
    let turn = (await this.native.feed(
      code,
      prepareInputs(options.inputs, this.instances),
      mountsToNative(options.mount),
      { cwd: options.cwd, skipTypeCheck: options.skipTypeCheck ?? false },
      onPrint,
    )) as NativeTurn
    for (;;) {
      switch (turn.kind) {
        case 'complete':
          printTarget.throwIfFailed()
          return restore(turn.value, this.instances)
        case 'error':
          printTarget.throwIfFailed()
          throw montyErrorFromNative(turn.exception)
        case 'typingError':
          printTarget.throwIfFailed()
          throw new MontyTypingError(turn.diagnostics)
        case 'crashed':
          throw this.poison(new MontyCrashedError(turn.message, turn))
        case 'protocol':
          throw this.poison(new ProtocolError(turn.message))
      }
      // Print failures take precedence. On a suspension the worker is waiting
      // for a resume we will never send — poison so the next feed fails cleanly
      // (matches Python pool: discard checkout when print fails mid-suspend).
      try {
        printTarget.throwIfFailed()
      } catch (err) {
        throw this.poison(err instanceof Error ? err : new Error(String(err)))
      }
      try {
        turn = await answerer.answer(turn, onPrint)
      } catch (err) {
        // A handler that throws instead of answering leaves the worker
        // suspended, awaiting a resume that will never come — the session

View on GitHub (pinned to adc986b362)

Solutions

1. Read `error.diagnostics` and fix the reported lines in the fed code
2. Set `typeCheck: false` in checkout/feed options if type checking is not required
3. Narrow or annotate the code (type hints) so the checker accepts the intended types

Example fix

// before
const result = await session.feedRun('x.upper()', { typeCheck: true }) // x: int
// after
const result = await session.feedRun("x: str = 'hi'\nx.upper()", { typeCheck: true })

try {
  const result = await session.feedRun(code, { typeCheck: true })
} catch (e) {
  if (e instanceof MontyTypingError) {
    for (const d of e.diagnostics) console.error(`${d.location ?? ''}: ${d.message}`)
  } else throw e
}

When it happens

Trigger: `session.feedRun(code, { typeCheck: true })` (or checkout with `typeCheck: true`) where the code fails type checking, e.g. wrong attribute use, argument type mismatch against typeshed stubs.

Common situations: Running a Monty-incompatible API the stubs don't know, feeding dynamically built code that doesn't type-check, upgrading code that used to skip type checking.

Related errors

• unknown typeCheckFormat '${format}', expected one of: ${Obje
• ClassInstance expects an object instance
• notCallableMessage(method)
• ClassInstance expects an instance of a class, not a null-pro
• classType does not match the instance's class

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