vectordotdev/vector · error · syn::Error

expected a string literal for the {component_type} name (i.e

Error message

expected a string literal for the {component_type} name (i.e. `{component_type_attr}("...")`)

What it means

Compile-time error from Vector's component-name derive (lib/vector-config-macros/src/component_name.rs). After `#[configurable_component(source)]` etc. is expanded into a helper attribute like `#[source_component(...)]`, the derive parses the parenthesized payload with `attr.parse_args::<LitStr>()`. If that parse fails, the payload is not exactly one string literal, and this error is emitted on the attribute span.

Source

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

    let component_type = component_type_attr.replace('_', " ");

    // Make sure the attribute actually has inner tokens. If it doesn't, this means they forgot
    // entirely to specify a component name, and we want to give back a meaningful error that looks
    // correct when applied in the context of `#[configurable_component(...)]`.
    if attr.meta.require_list().is_err() {
        return Err(Error::new(
            attr.span(),
            format!(
                "{component_type}s must have a name specified (e.g. `{component_type_attr}(\"my_component\")`)"
            ),
        ));
    }

    // 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.

View on GitHub (pinned to 3708c39b12)

Solutions

  1. Quote the name: change `#[configurable_component(source(my_source))]` to `#[configurable_component(source("my_source"))]`
  2. Put exactly one string literal inside the parentheses — no second argument, no trailing tokens
  3. Do not compute the name via consts or macros; hard-code the literal string

Example fix

// before
#[configurable_component(source(my_source))]
struct MySource;

// after
#[configurable_component(source("my_source"))]
struct MySource;
Defensive patterns

Strategy: validation

Validate before calling

# CI gate: fail fast on malformed component attributes
cargo check --workspace --all-targets

Prevention

When it happens

Trigger: Writing the component name unquoted: `#[configurable_component(source(my_source))]`; passing multiple tokens like `source("a", "b")`; passing an expression, const, or macro call (e.g. `source(concat!(...))`) instead of a literal; leaving stray tokens like `source("name" = )`.

Common situations: Contributors adding a new source/sink/transform/enrichment table who copy a sketch where the name was a bare identifier, or who try to build the name from a constant or `concat!` (proc macros only see tokens, so computed values cannot work).

Related errors


AI-assisted analysis of vectordotdev/vector@3708c39b12 (2026-08-20). Data as JSON: /api/errors/86fa7160883ca4d6. Report an issue: GitHub.