kestra-io/kestra · error · PebbleException

The 'errorLogs' function can only be used in the Worker as i

Error message

The 'errorLogs' function can only be used in the Worker as it access logs from the database.

What it means

Thrown by the Pebble 'errorLogs' function when pebbleUtils.get().calledOnWorker() returns false. The function reads logs from the database via executionLogMetaStore, an accessor that is only valid inside a Worker task execution. Calling it elsewhere (e.g. in flow-level rendering, triggers, or the webserver) is unsupported because the log store and the flow/execution context variables it needs are not available there.

Source

Thrown at core/src/main/java/io/kestra/core/runners/pebble/functions/ErrorLogsFunction.java:45

    @Inject
    private Provider<PebbleUtils> pebbleUtils;

    @Override
    public List<String> getArgumentNames() {
        return Collections.emptyList();
    }

    @Override
    public Map<String, String> getArgumentDefaults() {
        return Map.of();
    }

    @Override
    @SuppressWarnings("unchecked")
    public Object execute(Map<String, Object> args, PebbleTemplate self, EvaluationContext context, int lineNumber) {
        if (!pebbleUtils.get().calledOnWorker()) {
            throw new PebbleException(null, "The 'errorLogs' function can only be used in the Worker as it access logs from the database.", lineNumber, self.getName());
        }

        Map<String, String> flow = (Map<String, String>) context.getVariable("flow");
        Map<String, String> execution = (Map<String, String>) context.getVariable("execution");

        RetryUtils.Instance<List<LogEntry>, Throwable> retry = RetryUtils.of(
            Exponential.builder()
                .delayFactor(2.0)
                .interval(Duration.ofMillis(100))
                .maxInterval(Duration.ofSeconds(1))
                .maxAttempts(-1)
                .maxDuration(Duration.ofSeconds(5))
                .build()
        );

        try {
            return retry.run(logs -> ListUtils.isEmpty(logs), () -> executionLogMetaStore.get().errorLogs(flow.get("tenantId"), execution.get("id")));
        } catch (RetryUtils.RetryFailed e) {

View on GitHub (pinned to 823fada927)

Solutions

Move the errorLogs() call into a property that is evaluated by a worker task (e.g. a Log, Shell, or io.kestra task's input), not a flow-level or trigger-level field.
If you need the logs in a different context, capture them inside the worker task and pass the result downstream via outputs/outputs variables.
Confirm the task type actually executes on the worker (not an executor/scheduler-only component).

Example fix

# before - errorLogs() at trigger level is rejected
tasks:
  - id: warn
    type: io.kestra.plugin.core.log.Log
    message: "{{ errorLogs() }}"
# errorLogs() is fine here because Log runs on the worker; ensure you are NOT calling it in triggers/flow-level fields

Defensive patterns

Strategy: validation

Validate before calling

# errorLogs() is valid only in worker tasks. Before adding it, confirm the field is evaluated by a worker-executed task.
# Static guidance: only call errorLogs() inside a task input (e.g. io.kestra.plugin.core.log.Log), never in triggers or flow-level fields.

Prevention

Only call errorLogs() inside tasks that run on the worker.
Never place it in trigger, schedule, or flow-level properties.
Capture logs in a worker task and pass results downstream via outputs if needed elsewhere.
Review where a template field is rendered before using context-dependent functions.

When it happens

Trigger: Using errorLogs() in a flow-level property (e.g. on a trigger, a schedule, or top-level description), in a subflow mapping evaluated outside the worker, or in any template rendered before/at dispatch rather than during task execution on a worker.

Common situations: Putting errorLogs() in an SLA/alert field, a trigger configuration, or an error flow's inputs; rendering a summary string at the flow level instead of inside a task that runs on the worker.

Related errors

AI-assisted analysis of kestra-io/kestra@823fada927 (2026-08-14). Data as JSON: /api/errors/c15a66adb797e85e. Report an issue: GitHub.