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

  1. Check that the trigger was created with the correct trigger specification: WAL plugins should use 'every' (scheduled) triggers, e.g. CREATE TRIGGER ... EVERY 1h.
  2. 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.
  3. Verify all InfluxDB 3 node versions in the cluster are consistent; upgrade/mixed versions can mismatch trigger specification routing.
  4. 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

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


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)