ErrLookup › Background articles › "Must pass :limit option" / "Missing required option" — required option errors explained

"Must pass :limit option" / "Missing required option" — required option errors explained

Errors like "Must pass :limit option", "Missing required option '--account'", "Option \"implements\" is required" all come from the same guard: a library checks its options object or command-line flags up front and refuses to run when a mandatory one is absent, nil, or misspelled. This article explains where these fail-fast checks live, why they fire before any real work happens, and how to fix the option your call is actually missing.

Distilled from 106 documented records across 41 repositories.

Background

This family lives at configuration boundaries. Before a library does any real work — rendering a grid, starting a throttle counter, constructing a MapFile writer, building an OAuth URL — it validates that the options it was handed contain everything it cannot guess. The check is usually one line: Ruby's 'options[:limit] or raise ArgumentError', Rust's expect() on an Option field, a JavaScript throw when a required key is undefined. Because it fires at construction, initialization, or first call, you meet it at boot time, in an initializer, or on the very first request — not deep inside a failing operation.

The reason these checks exist is that the missing option has no sensible default. Rack::Attack's Fail2Ban needs bantime, findtime, and maxretry because a ban without a duration or a counting window is meaningless; Grape's coerce_with needs a type because knowing HOW to convert a parameter is useless without knowing WHAT it becomes; Hadoop's MapFile.Writer needs exactly one of keyClass or comparator because giving neither leaves the sort order undefined. Rather than silently misbehave — never banning, coercing wrongly, sorting unpredictably — the library fails closed with a message that names the missing piece.

From the caller's side, the error usually points at an honest omission or a config plumbing failure. Options built from environment variables are the biggest offender across these records: ENV['MAXRETRY'] unset yields nil, and the truthiness-based checks (common in Ruby) treat nil and false exactly like a missing key. Misspelled keys are the second pattern — the API wants :findtime and you wrote :find_time, or entryTypes with a lowercase t, and the validation sees nothing at all. A third pattern is programmatic use: the error surfaces in code paths the library's own CLI or interactive prompt normally shields (kamal's CLI pre-checks --account before the adapter raises, Angular's CLI prompts for --implements before the schematic throws).

The details vary by library in ways worth knowing. Some checks are exact-count rules, not just presence rules: Hadoop's MapFile.Writer requires exactly one of two options — passing both raises too. Some checks are order- or context-sensitive: kamal's Doppler adapter only needs --from=project/config when no DOPPLER_TOKEN is set, and inspects only the first secret. Some messages interpolate what's missing (rack-attack's "Must pass #{opt.inspect} option" tells you the exact symbol; puppet's trollop names the flag), while others are fixed strings that force you to read the surrounding documentation to know which option was at fault.

Common causes

What usually fixes it

Documented occurrences

…and 86 more across the corpus — use search.

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