vectordotdev/vector · error

global log_schema.source_type_key to be valid path

Error message

global log_schema.source_type_key to be valid path

What it means

This panic occurs during InfluxDB logs sink construction when neither a user-configured source_type_key nor the global log_schema().source_type_key() yields a value. Vector requires every event to have a source_type key path to build its line-protocol output, so the code treats the absence as an unrecoverable configuration invariant. The message comes from Rust's Option::expect, meaning an internally guaranteed value was None.

Solutions

  1. Set source_type_key explicitly on the influxdb logs sink configuration (e.g. source_type_key: "source_type").
  2. Restore the default global log_schema so log_schema().source_type_key() returns the default "source_type" path.
  3. Check for config preprocessing/templating that strips the log_schema block, and fix the generator.

Example fix

// before (vector.yaml)
log_schema:
  message_key: message

// after
log_schema:
  message_key: message
  source_type_key: source_type
Defensive patterns

Strategy: validation

Validate before calling

// vector.yaml — ensure the key exists before deploying
grep -q 'source_type_key' vector.yaml || echo 'source_type_key: source_type' >> vector.yaml

Prevention

When it happens

Trigger: Building the InfluxDB logs sink (InfluxDbLogsSink::new / healthcheck setup) with no explicit source_type_key on the sink and log_schema().source_type_key() returning None, e.g. a customized global log_schema configuration that omits or nulls the source_type key.

Common situations: Deployments where the global log_schema section in vector.toml/vector.yaml overrides keys and accidentally removes source_type; copying a minimal config that assumes defaults after a Vector version changed default schema handling; programmatic config generation that drops schema defaults.

Understand the failure class

Background: "missing required config value" errors: why libraries refuse to start when a configuration key is empty, unset, or blank — this error's family across 48 libraries.

Related errors


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

Appendix: source

Thrown at src/sinks/influxdb/logs.rs:322

        let client = HttpClient::new(tls_settings, cx.proxy())?;
        let healthcheck = self.healthcheck(client.clone())?;

        let request = self.request.into_settings();

        // Resolve the `log_schema()` fallbacks here, after the global log schema
        // has been initialized, so custom global log schema keys are honored.
        let host_key = host_key
            .clone()
            .or_else(|| log_schema().host_key().cloned())
            .expect("global log_schema.host_key to be valid path");
        let message_key = message_key
            .clone()
            .or_else(|| log_schema().message_key().cloned())
            .expect("global log_schema.message_key to be valid path");
        let source_type_key = source_type_key
            .clone()
            .or_else(|| log_schema().source_type_key().cloned())
            .expect("global log_schema.source_type_key to be valid path");

        let sink = InfluxDbLogsSink {
            uri: uri.clone(),
            token: token.inner().to_owned(),
            protocol_version: *protocol_version,
            measurement: measurement.clone(),
            tags: tags.clone(),
            transformer: self.encoding.clone(),
            host_key,
            message_key,
            source_type_key,
        };

        let sink = BatchedHttpSink::new(
            sink,
            Buffer::new(batch.size, Compression::None),
            request,
            batch.timeout,

View on GitHub (pinned to bdb87aeaa4)