influxdata/influxdb · warning · PluginError

request trigger execution cancelled

Error message

request trigger execution cancelled

What it means

Request-trigger plugin execution spawns the Python plugin and races it against a CancellationToken with tokio::select!. If cancellation wins — the HTTP client disconnected or the request was cancelled while the plugin ran — the worker returns Err('request trigger execution cancelled') and abandons the plugin task. This is an expected outcome of client-driven cancellation, not a plugin crash; any side effects the plugin already committed are kept.

Source

Thrown at influxdb3_processing_engine/src/worker/local.rs:474

                plugin_code_str.as_ref(),
                schema,
                query_endpoint,
                write_endpoint,
                logger,
                &trigger_arguments,
                query_params,
                headers,
                body,
                py_cache,
                plugin_root.as_deref(),
                plugin_cancel,
            )
        });

        let result = tokio::select! {
            joined = plugin => joined?,
            _ = cancel.cancelled() => {
                return Err(anyhow!("request trigger execution cancelled").into());
            }
        };

        match result {
            Ok((response_code, response_headers, response_body, plugin_return_state)) => {
                self.handle_successful_run(plugin_return_state, &run_logger, "request plugin")
                    .await;

                Ok(TriggerResponse {
                    status_code: response_code,
                    headers: response_headers,
                    body: response_body,
                })
            }
            Err(error) => Err(PluginError::PluginExecutionError(error)),
        }
    }

View on GitHub (pinned to d28e26e048)

Solutions

1. Raise the client/proxy timeout above the plugin's worst-case runtime so the connection survives
2. Profile and shorten the plugin: avoid sleeps, bound loops, cache expensive setup in module scope
3. Treat the error as expected during shutdown/draining and don't alert on it
4. If partial plugin work is undesirable, make the plugin idempotent so a retry after cancellation is safe

Example fix

# before: proxy cuts the connection at 30s while the plugin runs
location /api/v3/engine/request/ingest { proxy_read_timeout 30s; }

# after: timeout sized to the plugin's worst case
location /api/v3/engine/request/ingest { proxy_read_timeout 120s; }

# client side: set a timeout >= worst-case plugin runtime so the call isn't aborted
# e.g. curl --max-time 120 ".../api/v3/engine/request/<plugin>"

match worker.run_request(/* ... */).await {
    Err(e) if e.to_string().contains("request trigger execution cancelled") => {
        // client went away or shutdown: not a plugin bug — respond/drain quietly
        Ok(StatusCode::from_u16(499)?)
    }
    other => other,
}

When it happens

Trigger: An HTTP request trigger whose plugin is still running when the caller goes away: curl killed, browser fetch aborted, reverse proxy/gateway timeout firing (504 then close), or server shutdown during in-flight request-trigger calls.

Common situations: Plugins doing slow work (outbound HTTP calls, big loops, sleeps) behind aggressive proxy timeouts; load balancer idle timeouts shorter than plugin runtime; clients with short SDK timeouts hitting a request trigger endpoint.

Related errors

• No plugin directory configured
• Plugin not found: {}
• Failed to rename temp directory to target
• invalid database name: {db_name}
• unsupported Arrow type for Python conversion: {:?}. Supporte

AI-assisted analysis of influxdata/influxdb@d28e26e048 (2026-08-16). Data as JSON: /api/errors/8e42e2c77d1423aa. Report an issue: GitHub.