Workflow/tasks/try_catch.md

try_catch — Fehlergrenze mit Retry-Policy

Zweck: Umschließt beliebige Tasks: Wirft einer davon einen Fehler (TaskResult error oder PHP-Exception), bricht nicht mehr der ganze Workflow ab. Stattdessen wird — nach optionalen automatischen Wiederholungen mit Backoff — der <catch>-Zweig ausgeführt (z. B. Admin-Mail, Ersatzwert setzen) und der Workflow läuft weiter. Retries nutzen resume_at + cron-resume.

Parameter

Name	Pflicht?	Default	Beschreibung
try/task	ja	—	Zu überwachende Tasks (wie eine Sequenz)
retry (max)	nein	0	Anzahl automatischer Wiederholungen nach einem Fehler
retry (backoff)	nein	60	Wartezeiten in Sekunden je Versuch (CSV); letzter Wert gilt für weitere
catch/task	nein	—	Tasks nach erschöpften Retries; ohne <catch> wird der Fehler durchgereicht

Eingangswerte: Kontext der umschlossenen Tasks. Im <catch>-Zweig zusätzlich verfügbar:

• <task_id>_fehler — Fehlermeldung des letzten Versuchs
• <task_id>_versuche — Anzahl der Versuche

Ausgangswerte: Die Ausgaben der ausgeführten <try>- bzw. <catch>-Tasks landen im Kontext. Ohne <catch> endet der Task nach erschöpften Retries mit Fehler.

XML-Beispiel

<task type="try_catch" id="hkr_sicher">
  <try>
    <task type="webhook" id="an_hkr">…</task>
  </try>
  <retry max="3" backoff="60,300,3600"/>
  <catch>
    <task type="email" id="admin_info">…</task>
    <task type="set_var" id="fallback"><var name="hkr_status">manuell</var></task>
  </catch>
</task>

Hinweis: Bei einem Retry wird nur der fehlgeschlagene Kind-Task zurückgesetzt; der Task geht in waiting und plant den Neuversuch über resume_at. waiting/stop/return der Kind-Tasks werden unverändert durchgereicht.