vectordotdev/vector · error · syn::Error

{}

Error message

{}

What it means

Once the attribute's string literal is parsed, `check_component_name_validity` enforces Vector's naming rules (lowercase ASCII alphabetic characters). Any violation returns a `Result<(), String>` whose message is converted into a `syn::Error` at the string literal's span. The generic `{}` message here is that validation string propagated verbatim.

Solutions

  1. Rewrite the name using only lowercase ASCII letters (e.g. "mysource", "http_sink"-style digits are invalid — drop them)
  2. Read the validation message at the error span; it states the specific rule broken
  3. Check existing components in config/ for naming convention examples

Example fix

// before
#[component_name("My-Source_v2")]
struct MySourceConfig;
// after
#[component_name("mysource")]
struct MySourceConfig;
Defensive patterns

Strategy: validation

Validate before calling

fn valid_component_name(s: &str) -> bool {
    !s.is_empty() && s.chars().all(|c| c.is_ascii_lowercase())
}
assert!(valid_component_name("mysource"));

Prevention

When it happens

Trigger: Supplying a component name that violates the naming rules — uppercase letters, digits, hyphens, underscores, spaces, or non-ASCII characters — inside `#[component_name("...")]` or a kind attribute like `#[source("My-Source1")]`.

Common situations: Using kebab-case or snake_case out of habit; pasting a Rust type name (CamelCase) as the component name; adding version suffixes like `my_source_v2`.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors


AI-assisted analysis of vectordotdev/vector@bdb87aeaa4 (2026-09-16). Data as JSON: /api/errors/5e798bbbd4f5ce3c. Report an issue: GitHub.

Appendix: source

Thrown at lib/vector-config-macros/src/component_name.rs:155

            ),
        ));
    }

    // Now try and parse the helper attribute as a literal string, which is the only valid form.
    // After that, make sure it's actually valid according to our naming rules.
    attr.parse_args::<LitStr>()
        .map_err(|_| {
            Error::new(
                attr.span(),
                format!(
                    "expected a string literal for the {component_type} name (i.e. `{component_type_attr}(\"...\")`)"
                ),
            )
        })
        .and_then(|component_name| {
            let component_name_str = component_name.value();
            check_component_name_validity(&component_name_str)
                .map_err(|e| Error::new(component_name.span(), e))
                .map(|()| Some(component_name_str))
        })
}

fn check_component_name_validity(component_name: &str) -> Result<(), String> {
    // In a nutshell, component names must contain only lowercase ASCII alphabetic characters, or
    // numbers, or underscores.

    if component_name.is_empty() {
        return Err("component name must be non-empty".to_string());
    }

    // We only support ASCII names, so get that out of the way.
    if !component_name.is_ascii() {
        return Err("component names may only contain ASCII characters".to_string());
    }

    // Now, we blindly try and convert the given component name into the correct format, and

View on GitHub (pinned to bdb87aeaa4)