What causes "monty binary not found at binaryPath: ${explicit}" in pydantic/monty?

Verify the path exists at runtime: `existsSync(binaryPath)` before constructing the pool

pydantic/monty · error · Error

monty binary not found at binaryPath: ${explicit}

Error message

monty binary not found at binaryPath: ${explicit}

What it means

Thrown by `findMontyBinary` when an explicit `binaryPath` was supplied but no file exists at that path. The library trusts an explicit path as authoritative — it does not fall back to MONTY_BIN, the platform package, PATH, or the cargo workspace — so a wrong path fails fast with a message naming the exact path. This lets you distinguish 'you gave me a bad path' from 'I could not find any binary'.

Source

Thrown at crates/monty-js/ts/binary.ts:43

    return `darwin-${arch}`
  }
  if (platform === 'linux' && (arch === 'x64' || arch === 'arm64')) {
    return `linux-${arch}-gnu`
  }
  if (platform === 'win32' && arch === 'x64') {
    return 'win32-x64-msvc'
  }
  return null
}

/**
 * Resolves the `monty` binary path, throwing a descriptive error naming
 * every location tried when nothing is found.
 */
export function findMontyBinary(explicit?: string): string {
  if (explicit !== undefined) {
    if (!existsSync(explicit)) {
      throw new Error(`monty binary not found at binaryPath: ${explicit}`)
    }
    return explicit
  }

  const tried: string[] = []

  const envBin = process.env.MONTY_BIN
  if (envBin) {
    if (existsSync(envBin)) {
      return envBin
    }
    tried.push(`MONTY_BIN=${envBin}`)
  }

  const fromPackage = platformPackageBinary()
  if (fromPackage !== null) {
    return fromPackage
  }

View on GitHub (pinned to adc986b362)

Solutions

Verify the path exists at runtime: `existsSync(binaryPath)` before constructing the pool
Use an absolute path (`path.resolve(...)`) so it does not depend on the process cwd
On Windows point at the `.exe` (`monty.exe`), on other platforms at `monty`
If the path is optional, pass `undefined` instead of a bogus value so resolution falls through to MONTY_BIN / the platform package

Example fix

// before
const pool = await Monty.create({ binaryPath: './monty' }) // relative, may not exist
// after
import { existsSync } from 'node:fs'
const bin = path.resolve(process.env.MONTY_BIN ?? './target/debug/monty')
if (!existsSync(bin)) throw new Error(`monty binary missing at ${bin}`)
const pool = await Monty.create({ binaryPath: bin })

Defensive patterns

Strategy: validation

Validate before calling

import { existsSync, statSync } from 'node:fs'
function validateBinaryPath(p: string): string {
  if (!existsSync(p)) throw new Error(`monty binary missing at '${p}'`)
  if (!statSync(p).isFile()) throw new Error(`'${p}' is not a file`)
  return p
}
const pool = await Monty.create({ binaryPath: validateBinaryPath(myPath) })

Type guard

const isExistingFile = (p: string): boolean => { try { return statSync(p).isFile() } catch { return false } }

Try / catch

try {
  const pool = await Monty.create({ binaryPath: explicit })
} catch (err) {
  if ((err as Error).message.startsWith('monty binary not found at binaryPath')) {
    // fall back to auto-resolution: omit binaryPath entirely
    return Monty.create()
  }
  throw err
}

Prevention

Resolve with `path.resolve()` so the path is absolute and cwd-independent
Check `existsSync` at startup, before creating the pool
Never hard-code dev-machine paths; derive from env or config with validation
Remember `monty.exe` on Windows vs `monty` elsewhere

When it happens

Trigger: Calling `Monty.create({ binaryPath: ... })` (or any API that resolves the binary via `findMontyBinary(explicit)`) with a path that does not exist: a typo, a deleted binary after `cargo clean`, a relative path resolved from a different working directory, a path valid on a dev machine but not in CI/production.

Common situations: Hard-coding `target/debug/monty` from another checkout; Docker images built without copying the binary; switching from a local dev build to a production image where the workspace build is absent; platform suffix mistakes on Windows (`monty` instead of `monty.exe`).

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors

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