Question 1

Kestra itself never caches or reuses inputs between executions — every execution stores its own immutable set of inputs. If later runs keep showing the first run's values, the inputs are being resubmitted from somewhere. The usual suspects:

**1. The UI Execute form pre-fills previous values (most common)**
When you click *Execute* in the Kestra UI, the form remembers the last values you entered (stored in your browser's localStorage) and pre-fills them. If you just hit *Execute* again without editing, you get identical inputs every time. To verify, try executing from an incognito window or deliberately change a value in the form.

**2. Trigger-defined inputs**
If executions are created by a trigger that declares `inputs`, every run receives those static values:

```yaml
triggers:
  - id: daily
    type: io.kestra.plugin.core.trigger.Schedule
    cron: "0 9 * * *"
    inputs:
      env: prod   # identical on every run
```

Remove the `inputs` block from the trigger, or move the values into flow-level input `defaults` if you want them to be overridable per run.

**3. Replay/Restart**
Restarting or replaying an execution intentionally reuses the original inputs. Create a *New execution* instead if you want different values.

**4. Flow-level `defaults`**
If you don't pass inputs explicitly, every run falls back to the `defaults` defined in that flow revision. Editing the defaults creates a new revision — restarts of older executions stay pinned to the old revision's values. (Note: the current property is `defaults`; the old `default` was deprecated and removed in later 0.x releases.)

**5. An external caller resending the same payload**
A script, webhook, CI job, or a parent flow (`Subflow` task or Flow trigger with `inputs`) sending the same values on each invocation.

**How to pinpoint it**
- Open each execution's Overview page and inspect the *Inputs* section — it shows exactly what was submitted for that run.
- Check how the execution was created (manual vs. a specific trigger) in the execution context.
- If the source is manual UI runs and values match the first run, it's the pre-filled form. If the source is a trigger, inspect that trigger's `inputs` block in your flow YAML.

Accepted Answer

이는 Kestra 2.0에서 알려진 회귀 문제입니다(버전 1.3은 영향을 받지 않음): executor 측 속성 렌더링이 공유된 캐시 flow 객체에 렌더링된 값을 캐시하기 때문에, 첫 번째 실행에서 렌더링된 값(예: `{{ inputs.* }}`, `{{ now() }}`, trigger 변수)이 동일한 flow 리비전의 이후 모든 실행으로 유출됩니다. 영향을 받는 속성에는 `Pause` `pauseDuration`/`timeout`/`behavior`, `LoopUntil` `checkFrequency.maxIterations`, `Parallel`/`Dag` `concurrent`, `Subflow` `scheduleDate`, Webhook `responseCode`가 포함됩니다. 수정이 적용될 때까지의 해결 방법: (1) 동적 표현식을 사용하는 대신 속성 값을 하드코딩하거나, (2) 캐시가 재구축되도록 새로운 flow 리비전을 생성하거나, (3) Kestra 1.3.x로 다운그레이드하세요. executor에서 task가 속성을 읽는 방식을 변경하는 영구적인 수정이 PR #21061에서 진행 중이며, 릴리스되면 업그레이드하세요.

Question 2

SECRET 입력을 전달할 때 Kestra 웹훅 트리거가 500 오류 'String cannot be cast to Map'과 함께 실패하는 이유는 무엇인가요?

Accepted Answer

이는 Kestra 1.3.x의 알려진 버그입니다. `WebhookService.newExecution()`에서 원시 트리거 입력(예: `{{ trigger.body.session_secret }}`)이 렌더링되기 전에 실행에 첨부되므로, `RunVariables.build()`는 값이 아직 일반 String인 상태에서 SECRET 입력을 복호화하려고 시도하며, 이로 인해 `ClassCastException: String cannot be cast to Map`이 발생하고 플로우 실행이 시작되기 전에 500 응답이 반환됩니다. UI로 트리거된 실행은 실행 컨텍스트가 빌드되기 전에 입력이 암호화되므로 정상적으로 작동합니다.

**해결 방법: Kestra 2.0.0 이상으로 업그레이드하세요.** 이 버그는 PR #18318(2.0.0에서 릴리스됨)에서 수정되었으며, 해당 PR은 실행 컨텍스트가 빌드되는 동안 시크릿을 복호화하지 않도록 변경했습니다. 수정 후에는 웹훅에 매핑된 SECRET 입력이 UI로 트리거된 실행과 동일하게 올바르게 암호화된 상태로 실행에 전달됩니다. 이 수정은 회귀 테스트로 검증되었습니다. 해당 테스트는 #18318 이전 커밋에서는 실패하고 #18318부터는 통과합니다.

참고: 이 수정은 1.3.x 라인에 백포트된 적이 없으므로 업그레이드가 유일한 해결 방법입니다. 즉, 1.3.2에서는 웹훅 본문 값을 SECRET 타입 입력에 직접 매핑하지 않는 것 외에는 우회 방법이 없습니다.

Question 3

Pebble 목록을 결합하여 하위 흐름(subflow)에 전달할 때 Kestra 출력 변수가 덮어쓰여지는 이유는 무엇인가요?

Accepted Answer

이는 Pebble의 리스트 연결 연산자(+)가 첫 번째 리스트를 제자리에서 변경하기 때문에 발생합니다. 연결된 결과가 서브플로우에 입력으로 전달되면, 표현식의 첫 번째 리스트 변수가 영구적으로 수정되어 모든 결합된 값을 전달하게 됩니다. 해결 방법: 보존하려는 변수가 마지막에 오도록 표현식을 재정렬하세요. 예를 들어, `outputs.task.variable`을 표현식 끝으로 이동하십시오: `{{ (kv('key') | default([])) + (inputs.list | default([])) + (outputs.task.variable | default([])) }}`. 이렇게 하면 원래 출력이 그대로 유지됩니다. 또는, `| list`를 사용하여 연결 전에 리스트의 복사본을 생성하여 새로운 리스트를 강제로 만드십시오.

Question 4

건너뛴 모델이 포함된 dbt build 이후 실행에서 Kestra Gantt 차트가 비어 있는 이유는 무엇인가요?

Accepted Answer

상위 모델이 실패한 후 dbt가 하위 노드를 건너뛸 때 DbtCLI 태스크가 `parseRunResults: true`(기본값)로 실행되면 Gantt 탭이 충돌합니다(브라우저 콘솔에 `TypeError: Cannot read properties of undefined (reading 'date')`가 표시됨). 플러그인은 `state.histories`가 비어 있는(시작/종료 날짜 없음) SKIPPED 동적 태스크 실행을 생성하고, Gantt UI는 별도의 확인 없이 `state.histories[n].date`를 읽기 때문에 전체 차트 렌더링이 실패합니다. 해결 방법: `io.kestra.plugin.dbt.cli.DbtCLI` 태스크에서 `parseRunResults: false`로 설정하세요. Logs 탭은 영향을 받지 않으며 dbt 오류는 계속 표시됩니다. Kestra OSS v2.0.4 및 plugin-dbt 2.3.0에서 확인되었습니다.

Question 5

recoverMissedSchedules: LAST를 사용할 때 스케줄러가 시작 시 NullPointerException을 throw하는 이유는 무엇인가요?

Accepted Answer

NPE는 `TriggerScheduler.recoverMissedSchedules`(case `LAST`)에서 `getEvaluatedAt()`이 null 체크 없이 역참조되기 때문에 발생합니다. `TriggerState.of()`는 `evaluatedAt`을 `null`로 초기화하므로, 한 번도 평가되지 않은 트리거(스케줄러가 다운된 동안 배포된 경우, 비활성화 후 재활성화된 경우, 또는 cron이 먼 미래로 설정된 경우)는 스케줄러 시작 또는 리더 변경 시마다 복구를 크래시시킵니다. 이 예외는 `logError`로 삼켜지므로 시작 복구가 조용히 실패합니다. 수정: `TriggerEventHandler.updateForLastMissedSchedule`을 미러링하여 null-safe 스킵을 추가하세요 — `currentTriggerState.getEvaluatedAt() == null`이면 누락된 스케줄이 없으므로 복구를 건너뜁니다. 패치 전까지의 우회 방법: `LAST` 대신 `recoverMissedSchedules: ALL`(기본값)을 사용하거나, 재시작 전에 트리거가 최소 한 번은 평가되도록 하세요.

Kestra

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트