What causes "brew-cask:{}: unsupported {kind} {context} field {}" in jdx/mise?

Delete the key named in the message from that step object

brew-cask:{}: unsupported {kind} {context} field {}

Error message

brew-cask:{}: unsupported {kind} {context} field {}

What it means

reject_unsupported_flight_fields is the strict allow-list for every flight (preflight_steps/postflight_steps) container: step groups, individual steps, run commands, and guards. Unknown keys are collected, sorted alphabetically, and reported comma-joined in the message with the kind, context (e.g. 'remove step', 'run guard'), and cask token. Like the artifact variant, it exists so new Homebrew fields fail loudly instead of being silently ignored.

Source

Thrown at src/system/packages/brew/cask.rs:5995

    reject_unsupported_flight_fields(cask, kind, field, object, &["base", "path"])?;
    parse_context_flight_path(cask, kind, field, object)
}

fn reject_unsupported_flight_fields(
    cask: &Cask,
    kind: &str,
    context: &str,
    object: &serde_json::Map<String, Value>,
    allowed: &[&str],
) -> Result<()> {
    let mut unsupported = object
        .keys()
        .filter(|key| !allowed.contains(&key.as_str()))
        .cloned()
        .collect::<Vec<_>>();
    unsupported.sort();
    if !unsupported.is_empty() {
        bail!(
            "brew-cask:{}: unsupported {kind} {context} field {}",
            cask.token,
            unsupported.join(", ")
        );
    }
    Ok(())
}

fn parse_flight_path(
    cask: &Cask,
    kind: &str,
    field: &str,
    value: Option<&Value>,
) -> Result<FlightPath> {
    let object = value.and_then(Value::as_object).ok_or_else(|| {
        eyre!(
            "brew-cask:{}: unsupported {kind} {field} metadata format",
            cask.token

View on GitHub (pinned to 6f52dcdf99)

Solutions

Delete the key named in the message from that step object
Check the allowed list for the step type in parse_flight_step (src/system/packages/brew/cask.rs) to see where the field is actually supported
Update mise so newly supported fields parse; otherwise report the cask token upstream

Example fix

// before
{"type": "remove", "paths": ["/tmp/x"], "guards": []}
// after
{"type": "remove", "paths": ["/tmp/x"]}

Defensive patterns

Strategy: validation

Validate before calling

fn flight_fields_allowed(obj: &serde_json::Value, allowed: &[&str]) -> bool {
    obj.as_object().map(|o| o.keys().all(|k| allowed.contains(&k.as_str()))).unwrap_or(true)
}

Try / catch

match cask_artifacts(&cask) {
    Ok(a) => { /* proceed */ }
    Err(e) if e.to_string().contains("unsupported") && e.to_string().contains("field") => {
        eprintln!("cask {} uses a flight field outside this step's allow-list: {e}", cask.token);
    }
    Err(e) => return Err(e),
}

Prevention

Each step type has its own allowed option set — do not copy fields between step types
guards only belong on steps whose allow-list names them (copy/symlink/run)
Re-run custom casks through mise after upgrading to catch vocabulary drift early

When it happens

Trigger: e.g. a remove step carrying a "guards" key (guards are only allowed on copy/symlink/run): message 'brew-cask:<token>: unsupported postflight_steps remove step field guards'; or a step group with a stray "if" key: 'unsupported preflight_steps step group field if'.

Common situations: Homebrew metadata gaining new per-step options that older mise rejects; copy-pasting fields between step types that support different option sets; leftover experimental keys in hand-authored cask JSON.

Related errors

AI-assisted analysis of jdx/mise@6f52dcdf99 (2026-08-22). Data as JSON: /api/errors/22ed02b9028aa284. Report an issue: GitHub.