influxdata/influxdb · error · anyhow::Error
unexpectedly found request path trigger specification
Error message
unexpectedly found request path trigger specification {path} for WAL plugin {trigger_name} What it means
In the InfluxDB 3 Processing Engine, WAL triggers must use the 'every: <duration>' schedule form. When building the table filter for a WAL plugin run (make_wal_table_filter), the worker encountered a trigger whose TriggerSpecificationDefinition is a RequestPath instead of an Every-cron/duration form. This is an internal invariant violation: WAL workers should only ever be dispatched for WAL-compatible triggers, so a request-path trigger reaching this code path indicates a trigger routing or configuration bug.
Solutions
- Check that the trigger was created with the correct trigger specification: WAL plugins should use 'every' (scheduled) triggers, e.g. CREATE TRIGGER ... EVERY 1h.
- Inspect the trigger definition in the catalog and delete/recreate any trigger that was created with a request-path spec but registered for WAL processing.
- Verify all InfluxDB 3 node versions in the cluster are consistent; upgrade/mixed versions can mismatch trigger specification routing.
- If reproducible, report a bug with the trigger definition — this path indicates an internal invariant violation, not user input validation.
Example fix
-- before CREATE TRIGGER "wal-trig" ON DATABASE mydb FOR EACH WRITE WHEN * INSTEAD OF request ... -- after CREATE TRIGGER "wal-trig" ON DATABASE mydb FOR EACH WRITE WHEN * EVERY 1h ...
Defensive patterns
Strategy: validation
Validate before calling
// Only create WAL triggers with an 'every' specification
if (trigger.specification.type !== "every") {
throw new Error(`Trigger ${trigger.name} must use EVERY spec for WAL plugins, got: ${trigger.specification.type}`);
} Type guard
fn is_wal_trigger(spec: &TriggerSpecificationDefinition) -> bool {
matches!(spec, TriggerSpecificationDefinition::Every { .. })
} Prevention
- Always create WAL plugin triggers with EVERY <duration> specifications
- Audit trigger definitions in the catalog after version upgrades
- Keep all node versions in a cluster consistent
- Report internal dispatch bugs with the full trigger definition
When it happens
Trigger: A trigger created with 'CREATE TRIGGER ... WHEN ... INSTEAD OF request' (TriggerSpecificationDefinition::RequestPath) is somehow processed by the local WAL worker's execute_wal_once path, i.e. the WAL run loop attempts to build a table filter for a trigger that is not WAL-scheduled.
Common situations: A plugin developer or operator creates a request-path trigger (e.g. via HTTP trigger specification) but the internal scheduler/worker routing incorrectly hands it to the WAL worker, often after upgrading, migrating trigger definitions between node versions, or a bug in trigger dispatch. Not something end users hit through normal API use.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
- another process has written to the WAL ahead of this one
- bitcode error
- Cannot log
- crc32 checksum mismatch
- deserialize error
AI-assisted analysis of influxdata/influxdb@06200ef96b (2026-09-19).
Data as JSON: /api/errors/f784622547c58482.
Report an issue: GitHub.
Appendix: source
Thrown at influxdb3_processing_engine/src/worker/local.rs:579
TriggerSpecificationDefinition::SingleTableWalWrite { table_name } => {
let table_id = schema
.table_name_to_id(table_name)
.context("table not found")?;
Ok(Some(table_id))
}
TriggerSpecificationDefinition::Schedule { schedule } => Err(anyhow!(
"unexpectedly found scheduled trigger specification cron:{} for WAL plugin {}",
schedule,
self.trigger_definition.trigger_name
)
.into()),
TriggerSpecificationDefinition::Every { duration } => Err(anyhow!(
"unexpectedly found every trigger specification every:{} for WAL plugin {}",
format_duration(*duration),
self.trigger_definition.trigger_name
)
.into()),
TriggerSpecificationDefinition::RequestPath { path } => Err(anyhow!(
"unexpectedly found request path trigger specification {} for WAL plugin {}",
path,
self.trigger_definition.trigger_name
)
.into()),
}
}
fn log_return_state_errors(
&self,
logger: &ProcessingEngineLogger,
errors: &[anyhow::Error],
context: &str,
) {
for error in errors {
logger.log(
LogLevel::Error,
format!("error running {context}: {error:#}"),View on GitHub (pinned to 06200ef96b)