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
- Set source_type_key explicitly on the influxdb logs sink configuration (e.g. source_type_key: "source_type").
- Restore the default global log_schema so log_schema().source_type_key() returns the default "source_type" path.
- 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
- Always keep a complete log_schema block in your config when overriding any key.
- Run `vector validate` before deploying configs.
- Pin and review config templates that generate log_schema sections.
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
- static default endpoint should be a valid http(s) URL
- building HTTP request failed unexpectedly
- completing more than 2^16 data files at a time is obviously…
- event-time path requires AggregateConfig.event_time
- Failed type coercion
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)