Question 1

Why does my Kestra flow reuse the first execution's input values on all later runs of the same flow revision?

Accepted Answer

This is a known regression in Kestra 2.0 (version 1.3 is not affected): executor-side property rendering caches the rendered value on the shared, cached flow object, so the first execution's rendered values (e.g. `{{ inputs.* }}`, `{{ now() }}`, trigger variables) leak into every subsequent execution of the same flow revision. Affected properties include `Pause` `pauseDuration`/`timeout`/`behavior`, `LoopUntil` `checkFrequency.maxIterations`, `Parallel`/`Dag` `concurrent`, `Subflow` `scheduleDate`, and Webhook `responseCode`. Workarounds until the fix lands: (1) hardcode the property values instead of using dynamic expressions, or (2) create a new flow revision so the cache is rebuilt, or (3) downgrade to Kestra 1.3.x. A permanent fix changing how tasks read properties in the executor is in progress in PR #21061 — upgrade when it is released.

Question 2

Why does Kestra webhook trigger fail with 500 error 'String cannot be cast to Map' when passing a SECRET input?

Accepted Answer

This is a known bug in Kestra 1.3.x. In `WebhookService.newExecution()`, raw trigger inputs (e.g. `{{ trigger.body.session_secret }}`) are attached to the execution before rendering, so `RunVariables.build()` tries to decrypt the SECRET input while its value is still a plain String, causing a `ClassCastException: String cannot be cast to Map` and a 500 response before the flow execution starts. UI-triggered runs work because inputs are encrypted before the execution context is built.

**Fix: Upgrade to Kestra 2.0.0 or later.** The bug was fixed by PR #18318 (released in 2.0.0), which changed the run context to stop decrypting secrets while it is being built. After the fix, the webhook-mapped SECRET input reaches the execution properly encrypted, identical to a UI-triggered run. The fix was verified with a regression test: it fails on the commit before #18318 and passes from #18318 onward.

Note: the fix was never backported to the 1.3.x line, so upgrading is the only resolution — there is no workaround in 1.3.2 other than not mapping webhook body values directly onto SECRET-type inputs.

Question 3

Why does my Kestra output variable get overwritten when passing combined Pebble lists to a subflow?

Accepted Answer

This is caused by Pebble's list concatenation operator (+) mutating the first list in place. When the concatenated result is passed as an input to a subflow, the first list variable in the expression is permanently modified, carrying over all combined values. Workaround: reorder the expression so that the variable you want to preserve appears last. For example, move `outputs.task.variable` to the end of the expression: `{{ (kv('key') | default([])) + (inputs.list | default([])) + (outputs.task.variable | default([])) }}`. This keeps the original output intact. Alternatively, create a copy of the list before concatenation using `| list` to force a new list.

Question 4

Why is the Kestra Gantt chart empty for an execution after a dbt build with skipped models?

Accepted Answer

The Gantt tab crashes (browser console shows `TypeError: Cannot read properties of undefined (reading 'date')`) when a DbtCLI task runs with `parseRunResults: true` (the default) and dbt skips downstream nodes after an upstream model fails. The plugin creates SKIPPED dynamic task runs whose `state.histories` is empty (no start/end dates), and the Gantt UI reads `state.histories[n].date` without checking, so the whole chart fails to render. Workaround: set `parseRunResults: false` on the `io.kestra.plugin.dbt.cli.DbtCLI` task. The Logs tab is unaffected and still shows the dbt error. Observed on Kestra OSS v2.0.4 with plugin-dbt 2.3.0.

Question 5

Why does the scheduler throw NullPointerException on startup when using recoverMissedSchedules: LAST?

Accepted Answer

The NPE occurs in `TriggerScheduler.recoverMissedSchedules` (case `LAST`) because `getEvaluatedAt()` is dereferenced without a null check. `TriggerState.of()` initializes `evaluatedAt` to `null`, so any trigger that has never been evaluated (deployed while scheduler was down, disabled-then-re-enabled, or cron far in the future) crashes recovery at every scheduler start or leader change. The exception is swallowed into `logError`, so startup recovery silently fails. Fix: add a null-safe skip mirroring `TriggerEventHandler.updateForLastMissedSchedule` — if `currentTriggerState.getEvaluatedAt() == null`, skip recovery since there is no missed schedule. Workaround until patched: use `recoverMissedSchedules: ALL` (the default) instead of `LAST`, or ensure triggers are evaluated at least once before restarts.

Kestra

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects