dani-garcia/vaultwarden · error · Error

Failed to parse overrides

Error message

Failed to parse overrides

What it means

In the same init_logging() pass, capture group 2 carries the comma-separated ',target=level' override tail. This error fires only when caps.get(2) returns None (.ok_or on the Option). The regex lets the group repeat zero times, and a zero-repetition group still participates as an empty match, so Some("") is returned and this branch is effectively unreachable. Individual malformed override pairs are silently dropped by filter_map rather than reported.

Source

Thrown at src/main.rs:263

        let level = caps
            .get(1)
            .and_then(|m| log::LevelFilter::from_str(m.as_str()).ok())
            .ok_or(Error::new("Failed to parse global log level".to_owned(), ""))?;

        let levels_override: Vec<(&str, log::LevelFilter)> = caps
            .get(2)
            .map(|m| {
                m.as_str()
                    .split(',')
                    .collect::<Vec<&str>>()
                    .into_iter()
                    .filter_map(|s| match s.split_once('=') {
                        Some((log, lvl_str)) => log::LevelFilter::from_str(lvl_str).ok().map(|lvl| (log, lvl)),
                        _ => None,
                    })
                    .collect()
            })
            .ok_or(Error::new("Failed to parse overrides".to_owned(), ""))?;

        (level, levels_override)
    } else {
        err!(format!("LOG_LEVEL should follow the format info,vaultwarden::api::icons=debug, invalid: {config_str}"))
    };

    // Depending on the main log level we either want to disable or enable logging for hickory.
    // Else if there are timeouts it will clutter the logs since hickory uses warn for this.
    let hickory_level = if level >= log::LevelFilter::Debug {
        level
    } else {
        log::LevelFilter::Off
    };

    // Only show Rocket underscore `_` logs when the level is Debug or higher
    // Else this will bloat the log output with useless messages.
    let rocket_underscore_level = if level >= log::LevelFilter::Debug {
        log::LevelFilter::Warn

View on GitHub (pinned to 0cefa4cca7)

Solutions

1. Treat any occurrence as a build anomaly: diff init_logging() in src/main.rs against upstream
2. Validate LOG_LEVEL against the documented format and restart
3. Report upstream if a stock build reproduces it, since it indicates a regex/capture regression

# Same pre-start check; also list overrides so silent drops are visible
python3 - <<'EOF'
import os, re, sys
lvl = r'off|error|warn|info|debug|trace'
v = os.environ.get('LOG_LEVEL', 'info').strip().lower()
m = re.fullmatch(rf'({lvl})((,[^,=]+=({lvl}))*)', v)
if not m:
    sys.exit('LOG_LEVEL format invalid')
for part in m.group(2).split(','):
    if part:
        print('override:', part)
EOF

When it happens

Trigger: Only if the regex or capture layout changes so group 2 does not participate — e.g. a fork rewriting the pattern; the stock parser cannot produce this error for any input string.

Common situations: Essentially theoretical; shows up in static analysis / panic-path audits of the expect chain rather than real logs. Real override problems surface as silently dropped overrides or the sibling format error.

Understand the failure class

• Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

• Failed to parse global log level
• ConfigInvalid
• Grantee email does not exists
• Can't convert to number
• Error saving API key

AI-assisted analysis of dani-garcia/vaultwarden@0cefa4cca7 (2026-08-16). Data as JSON: /api/errors/eaee2604fddb3031. Report an issue: GitHub.