36 lines
1.8 KiB
Markdown
36 lines
1.8 KiB
Markdown
|
|
# `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**
|
||
|
|
|
||
|
|
```xml
|
||
|
|
<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.
|