ErrLookup › Background articles › "invalid argument", "unknown mode", "not supported": invalid enum-like argument errors explained

"invalid argument", "unknown mode", "not supported": invalid enum-like argument errors explained

"unknown update mode", "invalid period", "Unsupported method", "Invalid value for argument `output_mode`" — these are all variants of the invalid-enum-argument error family: a library raises ArgumentError, ValueError, or NotImplementedError because a string, symbol, or integer parameter must be one of a small closed set of values and the caller passed something outside it. Developers hit this when a typo, wrong casing, a string instead of a symbol, a synonym from another library's vocabulary, or a version mismatch sends an unrecognized value into a lookup that has no fallback.

Distilled from 89 documented records across 19 repositories.

Background

These errors come from the simplest defensive pattern in library code: a function that takes an option like mode, method, period, kind, or side looks it up in a fixed table or an if/elif chain, and if the key is missing, control reaches an else branch that raises. Because the parameter space is closed and enumerable, the library treats any other value as a caller bug rather than something it can recover from. The error is raised eagerly at the API boundary — a constructor in Keras layers, an argument check in a Faker generator, a primitive builder in JAX — so the failure happens at call time, not deep inside computation.

The failure modes cluster into a few recognizable groups. Type confusion is one: several libraries dispatch on symbols or enum members, so a plain string fails a hash-key comparison — ruby/ruby's mkdepend only recognizes the symbols :output, :stdout, :inplace, :check, faker-ruby/faker's TIME_RANGES lookup rejects 'morning' while accepting :morning, and fluentd's server helper only accepts the symbols :tcp, :udp, :tls, :unix. Case sensitivity is another: Faker normalizes some inputs with downcase or to_sym but still rejects 'Male' for danish_id_number's gender, JAX rejects mode='HIGH' for gumbel and side='LEFT' for searchsorted, and TradingAgents-CN requires exactly 'ema', 'sma', or 'china' in lowercase.

A third group is vocabulary drift: the caller uses a name that is valid in a neighboring library or an older version. Keras's RandomElasticTransform rejects fill_mode='replicate' and 'edge' because those are OpenCV and Pillow names, not Keras's; Faker::Stripe requires camelCase Stripe decline codes like 'addressZipFail', so snake_case guesses fail; jnp.linalg.vector_norm rejects ord='inf' even though NumPy users write string spellings, because JAX expects the float jnp.inf; and JAX's lu_solve wants trans as 0, 1, or 2, not SciPy's 'T'. Version skew between client and server or JS and wasm produces the same effect at the binary level — Hadoop throws 'Unknown OpenFileType' when a client's enum set matches no branch on the NameNode, and Flow's hermesParse rejects source_type values a newer JS bridge sends to an older wasm binary.

How much help you get varies by library. Some messages enumerate the accepted values — SGLang's "weight_prefix must be 'w13' or 'w2'", TradingAgents-CN's list of RSI methods, Keras's expected-output-mode set — while others just name the offending value, as in faker's "invalid period" or fluentd's terse "BUG: invalid protocol name". Some accepted sets are also locale- or version-dependent: which connection names Faker::Relationship.familial accepts depends on the loaded locale data, and which card types Faker::Stripe recognizes depends on the bundled YAML, so the reliable source of truth is the error message itself or the library's constant/locale keys, not a list copied from documentation.

Common causes

What usually fixes it

Documented occurrences

…and 69 more across the corpus — use search.

Honest provenance: generated on 2026-08-28 from AI-assisted analysis of the linked records. See how records are made.