{"id":332,"date":"2026-09-05T18:25:41","date_gmt":"2026-09-05T18:25:41","guid":{"rendered":"https:\/\/www.fabricioruch.ch\/?p=332"},"modified":"2026-09-05T18:25:42","modified_gmt":"2026-09-05T18:25:42","slug":"fehlerbehandlung-beginnt-dort-wo-der-happy-path-endet","status":"publish","type":"post","link":"https:\/\/www.fabricioruch.ch\/?p=332","title":{"rendered":"Fehlerbehandlung beginnt dort, wo der Happy Path endet"},"content":{"rendered":"\n

Software l\u00e4sst sich erstaunlich leicht demonstrieren.<\/p>\n\n\n\n

Man startet das Programm.<\/p>\n\n\n\n

Die Verbindung funktioniert.<\/p>\n\n\n\n

Die API antwortet.<\/p>\n\n\n\n

Alle Daten sind vorhanden.<\/p>\n\n\n\n

Jede Operation ist erfolgreich.<\/p>\n\n\n\n

Am Ende erscheint:<\/p>\n\n\n\n

SUCCESS\n<\/code><\/pre>\n\n\n\n
Damit ist bewiesen, dass der Happy Path funktioniert.<\/p>\n\n\n\n
Mehr aber auch nicht.<\/p>\n\n\n\n
Produktionsreife beginnt bei einer anderen Frage:<\/p>\n\n\n\n
\n
Was passiert, wenn die Operation nur teilweise funktioniert?<\/p>\n<\/blockquote>\n\n\n\n
Genau dort wird Fehlerbehandlung interessant.<\/p>\n\n\n\n
Nicht beim catch<\/code>-Block.<\/p>\n\n\n\n
Sondern bei der Frage, welchen Zustand das System nach einem Fehler tats\u00e4chlich besitzt.<\/p>\n\n\n\n
\n\n\n\n
Der Happy Path ist nur ein m\u00f6glicher Ablauf<\/h2>\n\n\n\n
Nehmen wir ein einfaches Tool, das Daten \u00fcber eine API ver\u00e4ndert.<\/p>\n\n\n\n
Der ideale Ablauf sieht so aus:<\/p>\n\n\n\n
Connect\n   \u2193\nDiscover\n   \u2193\nProcess\n   \u2193\nVerify\n   \u2193\nCompleted\n<\/code><\/pre>\n\n\n\n
Das l\u00e4sst sich einfach implementieren.<\/p>\n\n\n\n
Die Realit\u00e4t sieht eher so aus:<\/p>\n\n\n\n
Connect\n   \u251c\u2500\u2500 Authentication failed\n   \u251c\u2500\u2500 Permission denied\n   \u2514\u2500\u2500 Success\n          \u2193\nDiscover\n   \u251c\u2500\u2500 Timeout\n   \u251c\u2500\u2500 Pagination failure\n   \u2514\u2500\u2500 Success\n          \u2193\nProcess\n   \u251c\u2500\u2500 Success\n   \u251c\u2500\u2500 Partial success\n   \u251c\u2500\u2500 Rate limited\n   \u251c\u2500\u2500 Server error\n   \u2514\u2500\u2500 Connection lost\n          \u2193\nVerify\n   \u251c\u2500\u2500 Expected state reached\n   \u2514\u2500\u2500 Residual state remains\n<\/code><\/pre>\n\n\n\n
Das ist nicht die Ausnahme.<\/p>\n\n\n\n
Das ist der normale Zustandsraum eines verteilten Systems.<\/p>\n\n\n\n
\n\n\n\n
try\/catch<\/code> ist noch keine Fehlerstrategie<\/h1>\n\n\n\n
Eine typische erste Fehlerbehandlung sieht so aus:<\/p>\n\n\n\n
try {\n    Invoke-Something\n}\ncatch {\n    Write-Error $_\n}\n<\/code><\/pre>\n\n\n\n
Das ist technisch sinnvoll.<\/p>\n\n\n\n
Aber es beantwortet nur:<\/p>\n\n\n\n
\n
Ist eine Exception aufgetreten?<\/p>\n<\/blockquote>\n\n\n\n
Es beantwortet nicht:<\/p>\n\n\n\n
    \n
  • Was wurde bereits erfolgreich ausgef\u00fchrt?<\/li>\n\n\n\n
  • Was wurde nicht ausgef\u00fchrt?<\/li>\n\n\n\n
  • Was darf wiederholt werden?<\/li>\n\n\n\n
  • Was darf nicht wiederholt werden?<\/li>\n\n\n\n
  • Kann die Operation fortgesetzt werden?<\/li>\n\n\n\n
  • Ist der aktuelle Zustand bekannt?<\/li>\n\n\n\n
  • Muss der Benutzer eingreifen?<\/li>\n\n\n\n
  • Ist das Ergebnis verifiziert?<\/li>\n<\/ul>\n\n\n\n
    Das sind die eigentlich interessanten Fragen.<\/p>\n\n\n\n
    \n\n\n\n
    Fehler sind nicht alle gleich<\/h1>\n\n\n\n
    Ein wichtiger Schritt ist die Klassifikation von Fehlern.<\/p>\n\n\n\n
    Angenommen, eine API antwortet mit:<\/p>\n\n\n\n
    429 Too Many Requests\n<\/code><\/pre>\n\n\n\n
    Das bedeutet im Wesentlichen:<\/p>\n\n\n\n
    \n
    Nicht jetzt.<\/p>\n<\/blockquote>\n\n\n\n
    Ein:<\/p>\n\n\n\n
    500 Internal Server Error\n<\/code><\/pre>\n\n\n\n
    bedeutet eher:<\/p>\n\n\n\n
    \n
    Der Server konnte die Anfrage momentan nicht korrekt verarbeiten.<\/p>\n<\/blockquote>\n\n\n\n
    Ein:<\/p>\n\n\n\n
    403 Forbidden\n<\/code><\/pre>\n\n\n\n
    bedeutet dagegen:<\/p>\n\n\n\n
    \n
    Diese Operation ist nicht erlaubt.<\/p>\n<\/blockquote>\n\n\n\n
    Und ein:<\/p>\n\n\n\n
    400 Bad Request\n<\/code><\/pre>\n\n\n\n
    h\u00e4ufig:<\/p>\n\n\n\n
    \n
    Mit dieser Anfrage stimmt grunds\u00e4tzlich etwas nicht.<\/p>\n<\/blockquote>\n\n\n\n
    Diese Fehler sollten nicht identisch behandelt werden.<\/p>\n\n\n\n
    \n\n\n\n
    Retryable und Non-Retryable Errors<\/h1>\n\n\n\n
    Eine erste sinnvolle Klassifikation lautet:<\/p>\n\n\n\n
    Retryable\nNon-Retryable\n<\/code><\/pre>\n\n\n\n
    Typische Kandidaten f\u00fcr Retry:<\/p>\n\n\n\n
    429\n500\n502\n503\n504\nTimeout\ntempor\u00e4rer Netzwerkfehler\n<\/code><\/pre>\n\n\n\n
    Typische Kandidaten gegen blindes Retry:<\/p>\n\n\n\n
    400\n401\n403\n404\n<\/code><\/pre>\n\n\n\n
    Nat\u00fcrlich h\u00e4ngt die genaue Semantik von der jeweiligen API ab.<\/p>\n\n\n\n
    Der wichtige Punkt ist:<\/p>\n\n\n\n
    \n
    Retry ist eine fachliche Entscheidung, nicht einfach eine Reaktion auf jede Exception.<\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    Blindes Retry kann Probleme verschlimmern<\/h1>\n\n\n\n
    Dieser Code wirkt robust:<\/p>\n\n\n\n
    try {\n    Invoke-Operation\n}\ncatch {\n    Start-Sleep -Seconds 2\n    Invoke-Operation\n}\n<\/code><\/pre>\n\n\n\n
    Aber was passiert bei:<\/p>\n\n\n\n
    403 Forbidden\n<\/code><\/pre>\n\n\n\n
    ?<\/p>\n\n\n\n
    Man wartet zwei Sekunden und stellt dieselbe verbotene Anfrage erneut.<\/p>\n\n\n\n
    Oder bei:<\/p>\n\n\n\n
    400 Bad Request\n<\/code><\/pre>\n\n\n\n
    ?<\/p>\n\n\n\n
    Die Anfrage wird durch Warten nicht richtiger.<\/p>\n\n\n\n
    Retry ohne Klassifikation erzeugt nur zus\u00e4tzliche Last und verz\u00f6gert die eigentliche Fehlermeldung.<\/p>\n\n\n\n
    \n\n\n\n
    Retry braucht Grenzen<\/h1>\n\n\n\n
    Auch bei retrybaren Fehlern darf die Anwendung nicht endlos weitermachen.<\/p>\n\n\n\n
    Ein typisches Modell:<\/p>\n\n\n\n
    Attempt 1\n   \u2193 failed\n\nwait 1s\n\nAttempt 2\n   \u2193 failed\n\nwait 2s\n\nAttempt 3\n   \u2193 failed\n\nwait 4s\n\nFAILED\n<\/code><\/pre>\n\n\n\n
    Das ist Exponential Backoff<\/strong>.<\/p>\n\n\n\n
    Vereinfacht:<\/p>\n\n\n\n
    1\n2\n4\n8\n16\n...\n<\/code><\/pre>\n\n\n\n
    Dadurch h\u00e4mmert der Client bei einer St\u00f6rung nicht permanent auf den Server.<\/p>\n\n\n\n
    \n\n\n\n
    Retry-After<\/code> ist besser als Raten<\/h1>\n\n\n\n
    Bei HTTP 429<\/code> liefern APIs h\u00e4ufig einen Hinweis:<\/p>\n\n\n\n
    Retry-After: 10\n<\/code><\/pre>\n\n\n\n
    Dann sagt der Server explizit:<\/p>\n\n\n\n
    \n
    Versuche es in zehn Sekunden erneut.<\/p>\n<\/blockquote>\n\n\n\n
    In diesem Fall sollte der Client diese Information respektieren.<\/p>\n\n\n\n
    Also nicht:<\/p>\n\n\n\n
    Start-Sleep -Seconds 2\n<\/code><\/pre>\n\n\n\n
    sondern sinngem\u00e4\u00df:<\/p>\n\n\n\n
    Start-Sleep -Seconds $retryAfter\n<\/code><\/pre>\n\n\n\n
    Das ist ein kleines Detail mit gro\u00dfer Wirkung.<\/p>\n\n\n\n
    Eine robuste Anwendung arbeitet mit dem Server zusammen, statt gegen ihn.<\/p>\n\n\n\n
    \n\n\n\n
    Jitter verhindert synchronisierte Retries<\/h1>\n\n\n\n
    Bei vielen Clients entsteht noch ein anderes Problem.<\/p>\n\n\n\n
    Angenommen, ein Dienst f\u00e4llt kurz aus.<\/p>\n\n\n\n
    1’000 Clients erhalten gleichzeitig einen Fehler.<\/p>\n\n\n\n
    Alle warten exakt f\u00fcnf Sekunden.<\/p>\n\n\n\n
    Dann senden alle 1’000 Clients gleichzeitig erneut.<\/p>\n\n\n\n
    Der Dienst bekommt die n\u00e4chste Lastspitze.<\/p>\n\n\n\n
    Deshalb erg\u00e4nzt man Backoff h\u00e4ufig um zuf\u00e4llige Abweichung:<\/p>\n\n\n\n
    Backoff\n+\nJitter\n<\/code><\/pre>\n\n\n\n
    Aus:<\/p>\n\n\n\n
    5 Sekunden\n<\/code><\/pre>\n\n\n\n
    wird beispielsweise:<\/p>\n\n\n\n
    4.7 Sekunden\n5.3 Sekunden\n5.8 Sekunden\n...\n<\/code><\/pre>\n\n\n\n
    F\u00fcr ein einzelnes kleines PowerShell-Tool ist das vielleicht nicht entscheidend.<\/p>\n\n\n\n
    Das Konzept ist trotzdem wichtig, wenn man robuste verteilte Systeme verstehen will.<\/p>\n\n\n\n
    \n\n\n\n
    Ein erfolgreicher HTTP-Request bedeutet nicht automatisch Erfolg<\/h1>\n\n\n\n
    Nehmen wir an:<\/p>\n\n\n\n
    HTTP 200 OK\n<\/code><\/pre>\n\n\n\n
    Dann wissen wir zun\u00e4chst nur:<\/p>\n\n\n\n
    \n
    Die Anfrage wurde auf Protokollebene erfolgreich beantwortet.<\/p>\n<\/blockquote>\n\n\n\n
    Bei Batch-APIs wird es noch deutlicher.<\/p>\n\n\n\n
    Ein Batch-Request kann selbst erfolgreich sein:<\/p>\n\n\n\n
    HTTP 200\n<\/code><\/pre>\n\n\n\n
    w\u00e4hrend einzelne Operationen darin fehlschlagen.<\/p>\n\n\n\n
    Zum Beispiel:<\/p>\n\n\n\n
    Batch\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nRequest 1   200\nRequest 2   200\nRequest 3   429\nRequest 4   403\nRequest 5   200\n<\/code><\/pre>\n\n\n\n
    Der Batch war transporttechnisch erfolgreich.<\/p>\n\n\n\n
    Die fachliche Operation war es nur teilweise.<\/p>\n\n\n\n
    \n\n\n\n
    Partial Failure ist der Normalfall, den viele vergessen<\/h1>\n\n\n\n
    Stellen wir uns 20 \u00c4nderungen vor.<\/p>\n\n\n\n
    Das Ergebnis:<\/p>\n\n\n\n
    18 erfolgreich\n1 tempor\u00e4r fehlgeschlagen\n1 dauerhaft fehlgeschlagen\n<\/code><\/pre>\n\n\n\n
    Eine zu einfache Funktion liefert vielleicht:<\/p>\n\n\n\n
    return $false\n<\/code><\/pre>\n\n\n\n
    Das ist zu wenig Information.<\/p>\n\n\n\n
    Denn:<\/p>\n\n\n\n
    18 Operationen sind bereits erledigt.\n<\/code><\/pre>\n\n\n\n
    Ein komplettes Retry aller 20 Elemente k\u00f6nnte nun problematisch sein.<\/p>\n\n\n\n
    Deshalb sollte das Ergebnis pr\u00e4ziser sein.<\/p>\n\n\n\n
    Zum Beispiel:<\/p>\n\n\n\n
    [pscustomobject]@{\n    SucceededIds = @(...)\n    RetryIds     = @(...)\n    FailedIds    = @(...)\n}\n<\/code><\/pre>\n\n\n\n
    Jetzt wei\u00df die n\u00e4chste Schicht genau, was passiert ist.<\/p>\n\n\n\n
    \n\n\n\n
    Counts reichen irgendwann nicht mehr<\/h1>\n\n\n\n
    F\u00fcr eine Anzeige ist das hier praktisch:<\/p>\n\n\n\n
    [pscustomobject]@{\n    Succeeded = 18\n    Retrying  = 1\n    Failed    = 1\n}\n<\/code><\/pre>\n\n\n\n
    F\u00fcr Resume reicht es nicht.<\/p>\n\n\n\n
    Denn nach einem Neustart muss die Anwendung wissen:<\/p>\n\n\n\n
    \n
    Welche 18 Elemente waren erfolgreich?<\/p>\n<\/blockquote>\n\n\n\n
    Deshalb braucht man bei zustandsbehafteter Verarbeitung Identit\u00e4ten:<\/p>\n\n\n\n
    SucceededIds\nFailedIds\nPendingIds\n<\/code><\/pre>\n\n\n\n
    Nicht nur:<\/p>\n\n\n\n
    18\n1\n1\n<\/code><\/pre>\n\n\n\n
    Das ist ein gutes Beispiel daf\u00fcr, wie eine neue Anforderung das Datenmodell ver\u00e4ndert.<\/p>\n\n\n\n
    \n\n\n\n
    Fehlende Antworten sind ebenfalls ein Zustand<\/h1>\n\n\n\n
    Ein subtiler Fall entsteht bei Batch-Verarbeitung.<\/p>\n\n\n\n
    Man sendet:<\/p>\n\n\n\n
    20 Requests\n<\/code><\/pre>\n\n\n\n
    und erh\u00e4lt:<\/p>\n\n\n\n
    19 Responses\n<\/code><\/pre>\n\n\n\n
    Was ist mit Request Nummer 20?<\/p>\n\n\n\n
    Er ist nicht:<\/p>\n\n\n\n
    successful\n<\/code><\/pre>\n\n\n\n
    Aber auch nicht nachweislich:<\/p>\n\n\n\n
    failed\n<\/code><\/pre>\n\n\n\n
    Sein Zustand ist:<\/p>\n\n\n\n
    unknown\n<\/code><\/pre>\n\n\n\n
    Das ist wichtig.<\/p>\n\n\n\n
    Eine robuste Implementierung sollte deshalb vergleichen:<\/p>\n\n\n\n
    Sent Request IDs\n        -\nReceived Response IDs\n        =\nMissing Response IDs\n<\/code><\/pre>\n\n\n\n
    Diese fehlenden IDs m\u00fcssen bewusst behandelt werden.<\/p>\n\n\n\n
    Zum Beispiel erneut versucht oder als unbestimmt protokolliert werden.<\/p>\n\n\n\n
    Sie d\u00fcrfen nicht einfach verschwinden.<\/p>\n\n\n\n
    \n\n\n\n
    \u201eUnknown\u201c ist ein legitimer Zustand<\/h1>\n\n\n\n
    Entwickler modellieren gerne:<\/p>\n\n\n\n
    Success\nFailure\n<\/code><\/pre>\n\n\n\n
    Verteilte Systeme besitzen aber h\u00e4ufig einen dritten Zustand:<\/p>\n\n\n\n
    Unknown\n<\/code><\/pre>\n\n\n\n
    Beispiel:<\/p>\n\n\n\n
    Der Client sendet eine Anfrage.<\/p>\n\n\n\n
    Dann bricht die Netzwerkverbindung ab.<\/p>\n\n\n\n
    Hat der Server die Operation ausgef\u00fchrt?<\/p>\n\n\n\n
    Vielleicht.<\/p>\n\n\n\n
    Vielleicht nicht.<\/p>\n\n\n\n
    Der Client wei\u00df es nicht.<\/p>\n\n\n\n
    Das ist fundamental.<\/p>\n\n\n\n
    \n\n\n\n
    Genau hier wird Idempotenz wichtig<\/h1>\n\n\n\n
    Angenommen, die Operation lautet:<\/p>\n\n\n\n
    Set isRead = true\n<\/code><\/pre>\n\n\n\n
    Dann ist eine Wiederholung normalerweise unproblematisch:<\/p>\n\n\n\n
    false \u2192 true\n<\/code><\/pre>\n\n\n\n
    und erneut:<\/p>\n\n\n\n
    true \u2192 true\n<\/code><\/pre>\n\n\n\n
    Der Endzustand bleibt gleich.<\/p>\n\n\n\n
    Das ist eine idempotente Operation.<\/p>\n\n\n\n
    Vereinfacht:<\/p>\n\n\n\n
    \n
    Dieselbe Operation mehrfach auszuf\u00fchren erzeugt denselben Endzustand wie einmalige Ausf\u00fchrung.<\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    Nicht jede Operation ist idempotent<\/h1>\n\n\n\n
    Betrachten wir dagegen:<\/p>\n\n\n\n
    Create invoice\n<\/code><\/pre>\n\n\n\n
    Wenn die Antwort verloren geht und wir die Operation erneut ausf\u00fchren, k\u00f6nnten zwei Rechnungen entstehen.<\/p>\n\n\n\n
    Oder:<\/p>\n\n\n\n
    Charge credit card\n<\/code><\/pre>\n\n\n\n
    Ein blindes Retry w\u00e4re offensichtlich gef\u00e4hrlich.<\/p>\n\n\n\n
    Deshalb muss Retry immer zusammen mit der Frage betrachtet werden:<\/p>\n\n\n\n
    \n
    Ist diese Operation sicher wiederholbar?<\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    Idempotency Keys<\/h1>\n\n\n\n
    Viele APIs l\u00f6sen dieses Problem mit einem Idempotency Key.<\/p>\n\n\n\n
    Beispielsweise:<\/p>\n\n\n\n
    Idempotency-Key:\n550e8400-e29b-41d4-a716-446655440000\n<\/code><\/pre>\n\n\n\n
    Wird dieselbe Operation mit demselben Key erneut gesendet, kann der Server erkennen:<\/p>\n\n\n\n
    \n
    Diese Operation habe ich bereits verarbeitet.<\/p>\n<\/blockquote>\n\n\n\n
    Das verhindert doppelte Seiteneffekte.<\/p>\n\n\n\n
    Nicht jede API unterst\u00fctzt das.<\/p>\n\n\n\n
    Aber das zugrunde liegende Konzept ist f\u00fcr zuverl\u00e4ssige Integrationen zentral.<\/p>\n\n\n\n
    \n\n\n\n
    Retry und Idempotenz geh\u00f6ren zusammen<\/h1>\n\n\n\n
    Die Regel lautet deshalb nicht:<\/p>\n\n\n\n
    \n
    Bei Netzwerkfehlern einfach erneut versuchen.<\/p>\n<\/blockquote>\n\n\n\n
    Sondern:<\/p>\n\n\n\n
    Fehler\n  \u2193\nRetryable?\n  \u2193\nOperation idempotent?\n  \u2193\nZustand bekannt?\n  \u2193\nRetry sicher?\n<\/code><\/pre>\n\n\n\n
    Erst dann sollte die Wiederholung stattfinden.<\/p>\n\n\n\n
    \n\n\n\n
    Resume ist Retry \u00fcber Prozessgrenzen hinweg<\/h1>\n\n\n\n
    Retry passiert normalerweise innerhalb desselben Programmlaufs.<\/p>\n\n\n\n
    Resume erweitert dieselbe Idee.<\/p>\n\n\n\n
    Retry\n\u2192 Wiederholung innerhalb des Runs\n\nResume\n\u2192 Wiederaufnahme nach Ende des Runs\n<\/code><\/pre>\n\n\n\n
    Daf\u00fcr muss Zustand persistiert werden.<\/p>\n\n\n\n
    Zum Beispiel in einem Checkpoint.<\/p>\n\n\n\n
    \n\n\n\n
    Was ist ein Checkpoint?<\/h1>\n\n\n\n
    Ein Checkpoint speichert gen\u00fcgend Informationen, um nach einem Abbruch sinnvoll weiterarbeiten zu k\u00f6nnen.<\/p>\n\n\n\n
    Beispielsweise:<\/p>\n\n\n\n
    {\n  \"runId\": \"12345\",\n  \"startedAt\": \"2026-09-05T14:00:00Z\",\n  \"succeededIds\": [\n    \"A\",\n    \"B\",\n    \"C\"\n  ]\n}\n<\/code><\/pre>\n\n\n\n
    Beim n\u00e4chsten Start kann die Anwendung erkennen:<\/p>\n\n\n\n
    A \u2192 bereits erledigt\nB \u2192 bereits erledigt\nC \u2192 bereits erledigt\nD \u2192 noch offen\n<\/code><\/pre>\n\n\n\n
    Sie muss nicht wieder bei null beginnen.<\/p>\n\n\n\n
    \n\n\n\n
    Ein Checkpoint ist keine Logdatei<\/h1>\n\n\n\n
    Das ist eine wichtige Unterscheidung.<\/p>\n\n\n\n
    Ein Log beantwortet:<\/p>\n\n\n\n
    \n
    Was ist passiert?<\/p>\n<\/blockquote>\n\n\n\n
    Ein Checkpoint beantwortet:<\/p>\n\n\n\n
    \n
    Was muss ich wissen, um korrekt weiterzumachen?<\/p>\n<\/blockquote>\n\n\n\n
    Das sind unterschiedliche Anforderungen.<\/p>\n\n\n\n
    Ein Log kann beispielsweise enthalten:<\/p>\n\n\n\n
    14:32:01 Processing A\n14:32:02 Processing B\n14:32:03 Retry B\n14:32:05 Processing C\n<\/code><\/pre>\n\n\n\n
    Ein Checkpoint braucht vielleicht nur:<\/p>\n\n\n\n
    {\n  \"succeededIds\": [\"A\", \"B\", \"C\"]\n}\n<\/code><\/pre>\n\n\n\n
    Die Datenstrukturen sollten deshalb nicht verwechselt werden.<\/p>\n\n\n\n
    \n\n\n\n
    \u201eProcessed\u201c ist ein gef\u00e4hrliches Wort<\/h1>\n\n\n\n
    Nehmen wir an, der Checkpoint speichert:<\/p>\n\n\n\n
    {\n  \"processedIds\": [\n    \"A\",\n    \"B\"\n  ]\n}\n<\/code><\/pre>\n\n\n\n
    Was bedeutet processed<\/code>?<\/p>\n\n\n\n
    F\u00fcr A:<\/p>\n\n\n\n
    Operation erfolgreich.\n<\/code><\/pre>\n\n\n\n
    F\u00fcr B:<\/p>\n\n\n\n
    Operation versucht, aber fehlgeschlagen.\n<\/code><\/pre>\n\n\n\n
    Wenn beide als \u201eprocessed\u201c gespeichert werden, entsteht beim Resume ein schwerer Fehler.<\/p>\n\n\n\n
    B wird \u00fcbersprungen.<\/p>\n\n\n\n
    Obwohl die gew\u00fcnschte \u00c4nderung nie erfolgreich war.<\/p>\n\n\n\n
    \n\n\n\n
    Pr\u00e4zise Sprache verhindert Fehler<\/h1>\n\n\n\n
    Besser:<\/p>\n\n\n\n
    AttemptedIds\nSucceededIds\nFailedIds\n<\/code><\/pre>\n\n\n\n
    Diese Begriffe haben klare Semantik.<\/p>\n\n\n\n
    F\u00fcr Resume ist meistens entscheidend:<\/p>\n\n\n\n
    SucceededIds\n<\/code><\/pre>\n\n\n\n
    Denn nur diese Elemente d\u00fcrfen sicher als erledigt betrachtet werden.<\/p>\n\n\n\n
    Das ist kein Naming-Detail.<\/p>\n\n\n\n
    Das ist Teil der Korrektheit.<\/p>\n\n\n\n
    \n\n\n\n
    Checkpoints brauchen eine Commit-Semantik<\/h1>\n\n\n\n
    Man kann das gedanklich \u00e4hnlich wie eine kleine Transaktion betrachten.<\/p>\n\n\n\n
    Operation versuchen\n        \u2193\nErfolg best\u00e4tigt?\n        \u2193\nJa\n        \u2193\nCheckpoint aktualisieren\n<\/code><\/pre>\n\n\n\n
    Nicht:<\/p>\n\n\n\n
    Operation versuchen\n        \u2193\nCheckpoint aktualisieren\n        \u2193\nsp\u00e4ter herausfinden, ob es funktioniert hat\n<\/code><\/pre>\n\n\n\n
    Der Checkpoint sollte den best\u00e4tigten Zustand<\/strong> repr\u00e4sentieren.<\/p>\n\n\n\n
    \n\n\n\n
    Wann sollte ein Checkpoint geschrieben werden?<\/h1>\n\n\n\n
    Hier entsteht ein Trade-off.<\/p>\n\n\n\n
    Angenommen, ein Folder enth\u00e4lt 10’000 Elemente.<\/p>\n\n\n\n
    Variante A:<\/p>\n\n\n\n
    10'000 verarbeiten\n\u2193\nCheckpoint schreiben\n<\/code><\/pre>\n\n\n\n
    Wenn bei Element 9’999 der Prozess abst\u00fcrzt, fehlen viele erfolgreiche Operationen im Checkpoint.<\/p>\n\n\n\n
    Variante B:<\/p>\n\n\n\n
    jedes Element\n\u2193\nCheckpoint schreiben\n<\/code><\/pre>\n\n\n\n
    Das ist sicherer, erzeugt aber sehr viele Schreiboperationen.<\/p>\n\n\n\n
    Eine pragmatische L\u00f6sung:<\/p>\n\n\n\n
    Batch verarbeiten\n\u2193\nerfolgreiche IDs \u00fcbernehmen\n\u2193\nCheckpoint schreiben\n<\/code><\/pre>\n\n\n\n
    Damit entspricht die Persistenz der nat\u00fcrlichen Arbeitseinheit.<\/p>\n\n\n\n
    \n\n\n\n
    Checkpoint-Schreiben selbst kann scheitern<\/h1>\n\n\n\n
    Auch das wird gerne vergessen.<\/p>\n\n\n\n
    Die Verarbeitung funktioniert.<\/p>\n\n\n\n
    Dann kann der Checkpoint nicht gespeichert werden:<\/p>\n\n\n\n
    Disk full\nPermission denied\nFile locked\n<\/code><\/pre>\n\n\n\n
    Was nun?<\/p>\n\n\n\n
    Die externe Operation ist bereits passiert.<\/p>\n\n\n\n
    Der lokale Zustand wurde aber nicht persistiert.<\/p>\n\n\n\n
    Genau deshalb ist Idempotenz wieder wichtig.<\/p>\n\n\n\n
    Beim Resume k\u00f6nnten bereits erfolgreiche Operationen erneut entdeckt werden.<\/p>\n\n\n\n
    Wenn deren Wiederholung sicher ist, bleibt das System beherrschbar.<\/p>\n\n\n\n
    \n\n\n\n
    Checkpoints sollten atomar geschrieben werden<\/h1>\n\n\n\n
    Ein weiteres Problem:<\/p>\n\n\n\n
    Das Programm schreibt eine JSON-Datei.<\/p>\n\n\n\n
    Mitten w\u00e4hrend des Schreibens st\u00fcrzt der Prozess ab.<\/p>\n\n\n\n
    Zur\u00fcck bleibt:<\/p>\n\n\n\n
    {\n  \"succeededIds\": [\n    \"A\",\n    \"B\",\n<\/code><\/pre>\n\n\n\n
    Der Checkpoint ist kaputt.<\/p>\n\n\n\n
    Eine typische Strategie:<\/p>\n\n\n\n
    checkpoint.tmp schreiben\n        \u2193\nvollst\u00e4ndig erfolgreich?\n        \u2193\nrename \/ replace\n        \u2193\ncheckpoint.json\n<\/code><\/pre>\n\n\n\n
    Das reduziert das Risiko eines teilweise geschriebenen Zustands.<\/p>\n\n\n\n
    \n\n\n\n
    Ein Checkpoint braucht m\u00f6glicherweise eine Version<\/h1>\n\n\n\n
    Heute sieht der Checkpoint so aus:<\/p>\n\n\n\n
    {\n  \"succeededIds\": []\n}\n<\/code><\/pre>\n\n\n\n
    In sechs Monaten vielleicht:<\/p>\n\n\n\n
    {\n  \"version\": 2,\n  \"runId\": \"...\",\n  \"scope\": \"...\",\n  \"succeededIds\": []\n}\n<\/code><\/pre>\n\n\n\n
    Ohne Versionierung kann ein neues Programm einen alten Checkpoint falsch interpretieren.<\/p>\n\n\n\n
    Deshalb kann selbst bei kleinen Tools sinnvoll sein:<\/p>\n\n\n\n
    {\n  \"schemaVersion\": 1\n}\n<\/code><\/pre>\n\n\n\n
    Das kostet fast nichts und schafft eine klare Evolutionsgrenze.<\/p>\n\n\n\n
    \n\n\n\n
    Resume muss den Kontext validieren<\/h1>\n\n\n\n
    Ein gespeicherter Checkpoint darf nicht blind verwendet werden.<\/p>\n\n\n\n
    Angenommen, der Checkpoint stammt von:<\/p>\n\n\n\n
    Mailbox A\n<\/code><\/pre>\n\n\n\n
    und der Benutzer startet:<\/p>\n\n\n\n
    Mailbox B\n<\/code><\/pre>\n\n\n\n
    Wenn nur Message IDs gespeichert sind, k\u00f6nnte das gef\u00e4hrlich werden.<\/p>\n\n\n\n
    Deshalb sollte ein Checkpoint seinen Kontext kennen:<\/p>\n\n\n\n
    Target\nUser\nOperation\nRun\nSchema Version\n<\/code><\/pre>\n\n\n\n
    Beim Resume kann gepr\u00fcft werden:<\/p>\n\n\n\n
    \n
    Passt dieser Checkpoint \u00fcberhaupt zu diesem Lauf?<\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    Ein Checkpoint ist kein Ersatz f\u00fcr Idempotenz<\/h1>\n\n\n\n
    Es w\u00e4re verf\u00fchrerisch zu sagen:<\/p>\n\n\n\n
    \n
    Wir speichern alle erfolgreichen IDs, also brauchen wir keine idempotenten Operationen.<\/p>\n<\/blockquote>\n\n\n\n
    Das stimmt nicht.<\/p>\n\n\n\n
    Zwischen:<\/p>\n\n\n\n
    Operation erfolgreich\n<\/code><\/pre>\n\n\n\n
    und:<\/p>\n\n\n\n
    Checkpoint erfolgreich gespeichert\n<\/code><\/pre>\n\n\n\n
    existiert immer ein kleines Zeitfenster.<\/p>\n\n\n\n
    Der Prozess kann genau dort abst\u00fcrzen.<\/p>\n\n\n\n
    Dann wurde die Operation durchgef\u00fchrt, aber nicht persistiert.<\/p>\n\n\n\n
    Beim n\u00e4chsten Start wird sie m\u00f6glicherweise erneut ausgef\u00fchrt.<\/p>\n\n\n\n
    Deshalb ist die Kombination stark:<\/p>\n\n\n\n
    Idempotente Operation\n+\nCheckpoint\n<\/code><\/pre>\n\n\n\n
    Nicht entweder\/oder.<\/p>\n\n\n\n
    \n\n\n\n
    Verification ist eine eigene Phase<\/h1>\n\n\n\n
    Nach erfolgreicher Verarbeitung kommt eine weitere Frage:<\/p>\n\n\n\n
    \n
    Ist der gew\u00fcnschte Endzustand tats\u00e4chlich erreicht?<\/p>\n<\/blockquote>\n\n\n\n
    Das sollte nicht automatisch aus den Operationen abgeleitet werden.<\/p>\n\n\n\n
    Angenommen:<\/p>\n\n\n\n
    56 \u00c4nderungen angefordert\n56 erfolgreiche Responses\n<\/code><\/pre>\n\n\n\n
    Das ist gut.<\/p>\n\n\n\n
    Aber der eigentliche Auftrag k\u00f6nnte lauten:<\/p>\n\n\n\n
    Es sollen keine ungelesenen Nachrichten mehr vorhanden sein.\n<\/code><\/pre>\n\n\n\n
    Dann ist die relevante Pr\u00fcfung:<\/p>\n\n\n\n
    Remaining unread = ?\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Operationserfolg und Zustandserfolg<\/h1>\n\n\n\n
    Diese Unterscheidung ist fundamental.<\/p>\n\n\n\n
    Operation Success\n<\/code><\/pre>\n\n\n\n
    bedeutet:<\/p>\n\n\n\n
    \n
    Die angeforderten Operationen wurden erfolgreich ausgef\u00fchrt.<\/p>\n<\/blockquote>\n\n\n\n
    State Success\n<\/code><\/pre>\n\n\n\n
    bedeutet:<\/p>\n\n\n\n
    \n
    Das System befindet sich jetzt im gew\u00fcnschten Zustand.<\/p>\n<\/blockquote>\n\n\n\n
    Beides kann auseinanderfallen.<\/p>\n\n\n\n
    \n\n\n\n
    Beispiel<\/h1>\n\n\n\n
    Wir entdecken:<\/p>\n\n\n\n
    56 ungelesene Nachrichten\n<\/code><\/pre>\n\n\n\n
    Wir \u00e4ndern alle 56.<\/p>\n\n\n\n
    Die API meldet:<\/p>\n\n\n\n
    56 erfolgreich\n<\/code><\/pre>\n\n\n\n
    W\u00e4hrenddessen kommt eine neue Nachricht an.<\/p>\n\n\n\n
    Post-Verification:<\/p>\n\n\n\n
    1 ungelesene Nachricht\n<\/code><\/pre>\n\n\n\n
    War die Verarbeitung erfolgreich?<\/p>\n\n\n\n
    Ja.<\/p>\n\n\n\n
    Ist der gew\u00fcnschte globale Zustand:<\/p>\n\n\n\n
    0 unread\n<\/code><\/pre>\n\n\n\n
    erreicht?<\/p>\n\n\n\n
    Nein.<\/p>\n\n\n\n
    Beide Aussagen k\u00f6nnen gleichzeitig wahr sein.<\/p>\n\n\n\n
    \n\n\n\n
    Verification braucht eine definierte Wahrheit<\/h1>\n\n\n\n
    Auch hier ist wichtig, was<\/strong> verifiziert wird.<\/p>\n\n\n\n
    Angenommen, eine API liefert Folder-Metadaten:<\/p>\n\n\n\n
    unreadItemCount = 10\n<\/code><\/pre>\n\n\n\n
    Eine konkrete Query:<\/p>\n\n\n\n
    isRead = false\n<\/code><\/pre>\n\n\n\n
    findet aber nur:<\/p>\n\n\n\n
    8\n<\/code><\/pre>\n\n\n\n
    Wenn wir bereits wissen, dass Metadaten und tats\u00e4chliche Query voneinander abweichen k\u00f6nnen, sollten wir bei der Post-Verification nicht pl\u00f6tzlich die Metadaten zur endg\u00fcltigen Wahrheit erkl\u00e4ren.<\/p>\n\n\n\n
    Die Verifikation sollte m\u00f6glichst dieselbe fachliche Definition verwenden wie die urspr\u00fcngliche Auswahl.<\/p>\n\n\n\n
    Also:<\/p>\n\n\n\n
    Pre-flight:\nisRead = false\n\nPost-flight:\nisRead = false\n<\/code><\/pre>\n\n\n\n
    Das macht die Semantik konsistent.<\/p>\n\n\n\n
    \n\n\n\n
    Verification ist nicht dasselbe wie Retry<\/h1>\n\n\n\n
    Wenn nach der Verarbeitung noch zwei Elemente \u00fcbrig sind, gibt es verschiedene M\u00f6glichkeiten.<\/p>\n\n\n\n
    Vielleicht:<\/p>\n\n\n\n
    zwei neue Elemente sind entstanden\n<\/code><\/pre>\n\n\n\n
    Vielleicht:<\/p>\n\n\n\n
    zwei urspr\u00fcngliche Operationen sind fehlgeschlagen\n<\/code><\/pre>\n\n\n\n
    Vielleicht:<\/p>\n\n\n\n
    eventual consistency\n<\/code><\/pre>\n\n\n\n
    Vielleicht:<\/p>\n\n\n\n
    falsche Query\n<\/code><\/pre>\n\n\n\n
    Deshalb sollte Verification zun\u00e4chst feststellen.<\/p>\n\n\n\n
    Nicht automatisch reparieren.<\/p>\n\n\n\n
    Observe\n\u2193\nClassify\n\u2193\nDecide\n<\/code><\/pre>\n\n\n\n
    Nicht:<\/p>\n\n\n\n
    Observe\n\u2193\nblind retry everything\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Eventual Consistency<\/h1>\n\n\n\n
    Verteilte Systeme k\u00f6nnen \u00c4nderungen verz\u00f6gert sichtbar machen.<\/p>\n\n\n\n
    Eine Mutation ist erfolgreich.<\/p>\n\n\n\n
    Direkt danach liefert eine andere Query noch den alten Zustand.<\/p>\n\n\n\n
    Kurz sp\u00e4ter stimmt alles.<\/p>\n\n\n\n
    Das nennt man Eventual Consistency<\/strong>.<\/p>\n\n\n\n
    Deshalb kann eine Verification-Strategie beispielsweise lauten:<\/p>\n\n\n\n
    Verify\n\u2193\nResidual state?\n\u2193\nkurz warten\n\u2193\nVerify again\n\u2193\nfinal result\n<\/code><\/pre>\n\n\n\n
    Auch hier sollten Retries begrenzt sein.<\/p>\n\n\n\n
    \n\n\n\n
    Erfolg braucht mehrere Ebenen<\/h1>\n\n\n\n
    F\u00fcr ein robustes Tool kann ein Ergebnis deshalb differenzierter aussehen:<\/p>\n\n\n\n
    [pscustomobject]@{\n    Attempted  = 56\n    Succeeded  = 55\n    Failed     = 1\n    Verified   = $false\n    Remaining  = 1\n}\n<\/code><\/pre>\n\n\n\n
    Das ist viel aussagekr\u00e4ftiger als:<\/p>\n\n\n\n
    $success = $false\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    SUCCESS<\/code> ist eine Behauptung<\/h1>\n\n\n\n
    Das ist besonders f\u00fcr TUIs relevant.<\/p>\n\n\n\n
    Ein gr\u00fcner Abschluss-Screen mit:<\/p>\n\n\n\n
    SUCCESS\n<\/code><\/pre>\n\n\n\n
    ist keine Dekoration.<\/p>\n\n\n\n
    Er ist eine fachliche Behauptung.<\/p>\n\n\n\n
    Die Anwendung sollte deshalb definieren, wann dieser Zustand erreicht ist.<\/p>\n\n\n\n
    Zum Beispiel:<\/p>\n\n\n\n
    Completed\n+\nFailed = 0\n+\nVerification completed\n+\nRemaining = 0\n<\/code><\/pre>\n\n\n\n
    Erst dann:<\/p>\n\n\n\n
    VERIFIED SUCCESS\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Es gibt mehr als Success und Failure<\/h1>\n\n\n\n
    Ein ausgereiftes Tool kann Ergebnisse besitzen wie:<\/p>\n\n\n\n
    Completed\nCompletedWithFailures\nVerificationFailed\nCancelled\nInterrupted\nResumeAvailable\nFailed\n<\/code><\/pre>\n\n\n\n
    Nicht jede Operation passt sinnvoll in:<\/p>\n\n\n\n
    true \/ false\n<\/code><\/pre>\n\n\n\n
    Gerade Batch-Systeme profitieren von pr\u00e4ziseren Endzust\u00e4nden.<\/p>\n\n\n\n
    \n\n\n\n
    Fehler sollten den n\u00e4chsten Schritt erkl\u00e4ren<\/h1>\n\n\n\n
    Eine Fehlermeldung wie:<\/p>\n\n\n\n
    HTTP 503\n<\/code><\/pre>\n\n\n\n
    ist technisch korrekt.<\/p>\n\n\n\n
    F\u00fcr den Benutzer ist hilfreicher:<\/p>\n\n\n\n
    PROCESSING INTERRUPTED\n\n117 \/ 184 items completed.\nThe service is temporarily unavailable.\n\nCheckpoint saved.\nThe operation can be resumed.\n<\/code><\/pre>\n\n\n\n
    Das beantwortet:<\/p>\n\n\n\n
    Was ist passiert?\nWas wurde bereits erledigt?\nIst der Zustand sicher?\nWas kann ich jetzt tun?\n<\/code><\/pre>\n\n\n\n
    Das ist gute Fehlerbehandlung.<\/p>\n\n\n\n
    \n\n\n\n
    Fehlerbehandlung ist Teil der UX<\/h1>\n\n\n\n
    Das wird oft untersch\u00e4tzt.<\/p>\n\n\n\n
    UX wird gerne mit:<\/p>\n\n\n\n
      \n
    • Farben<\/li>\n\n\n\n
    • Buttons<\/li>\n\n\n\n
    • Layout<\/li>\n\n\n\n
    • Animation<\/li>\n<\/ul>\n\n\n\n
      verbunden.<\/p>\n\n\n\n
      Bei technischen Werkzeugen entsteht gute UX aber besonders in Fehlerf\u00e4llen.<\/p>\n\n\n\n
      Ein gutes Tool sagt nicht nur:<\/p>\n\n\n\n
      Something went wrong.\n<\/code><\/pre>\n\n\n\n
      Es sagt:<\/p>\n\n\n\n
      was\nwo\nwie weit\nwelcher Zustand\nob Retry sinnvoll ist\nob Resume m\u00f6glich ist\n<\/code><\/pre>\n\n\n\n
      Das schafft Vertrauen.<\/p>\n\n\n\n
      \n\n\n\n
      Logging und Benutzeroberfl\u00e4che haben unterschiedliche Aufgaben<\/h1>\n\n\n\n
      Ein Log darf technisch sein:<\/p>\n\n\n\n
      2026-09-05T14:32:01Z\nPATCH \/messages\/abc\nHTTP 503\nattempt=3\n<\/code><\/pre>\n\n\n\n
      Die TUI sollte eher sagen:<\/p>\n\n\n\n
      SERVICE TEMPORARILY UNAVAILABLE\n\nRetry 3 \/ 5\nContinuing in 8 seconds\n<\/code><\/pre>\n\n\n\n
      Beides beschreibt dasselbe Ereignis.<\/p>\n\n\n\n
      Aber f\u00fcr unterschiedliche Zielgruppen.<\/p>\n\n\n\n
      \n\n\n\n
      Quiet Mode braucht ebenfalls saubere Fehler<\/h1>\n\n\n\n
      Maschinenlesbare Ausgabe sollte Fehler strukturiert liefern.<\/p>\n\n\n\n
      Nicht:<\/p>\n\n\n\n
      ERROR!!!\nSomething failed.\n<\/code><\/pre>\n\n\n\n
      sondern beispielsweise:<\/p>\n\n\n\n
      {\n  \"status\": \"partial_failure\",\n  \"processed\": 117,\n  \"failed\": 1,\n  \"remaining\": 67,\n  \"resumeAvailable\": true\n}\n<\/code><\/pre>\n\n\n\n
      Damit kann ein anderes Programm reagieren.<\/p>\n\n\n\n
      Fehlerbehandlung wird dadurch Teil des \u00f6ffentlichen Schnittstellenvertrags.<\/p>\n\n\n\n
      \n\n\n\n
      Exit Codes geh\u00f6ren dazu<\/h1>\n\n\n\n
      F\u00fcr CLI-Tools sind Exit Codes ebenfalls wichtig.<\/p>\n\n\n\n
      Zum Beispiel:<\/p>\n\n\n\n
      0\n\u2192 erfolgreich\n\n1\n\u2192 allgemeiner Fehler\n\n2\n\u2192 teilweise Verarbeitung\n\n3\n\u2192 Verifikation fehlgeschlagen\n<\/code><\/pre>\n\n\n\n
      Die konkrete Konvention ist projektspezifisch.<\/p>\n\n\n\n
      Entscheidend ist:<\/p>\n\n\n\n
      Ein automatisierter Aufrufer sollte nicht den Bildschirmtext analysieren m\u00fcssen, um herauszufinden, ob etwas funktioniert hat.<\/p>\n\n\n\n
      \n\n\n\n
      Fehlerbehandlung beginnt beim Design<\/h1>\n\n\n\n
      Die wichtigste Erkenntnis ist deshalb:<\/p>\n\n\n\n
      Robustheit kann nicht am Ende mit ein paar catch<\/code>-Bl\u00f6cken hinzugef\u00fcgt werden.<\/p>\n\n\n\n
      Bereits das Datenmodell muss Fehlerf\u00e4lle ausdr\u00fccken k\u00f6nnen.<\/p>\n\n\n\n
      Wenn eine Funktion nur:<\/p>\n\n\n\n
      $true\n<\/code><\/pre>\n\n\n\n
      oder:<\/p>\n\n\n\n
      $false\n<\/code><\/pre>\n\n\n\n
      zur\u00fcckgeben kann, kann sie keinen Partial Failure beschreiben.<\/p>\n\n\n\n
      Wenn ein Checkpoint nur:<\/p>\n\n\n\n
      ProcessedIds\n<\/code><\/pre>\n\n\n\n
      kennt, kann er Success und Failure nicht unterscheiden.<\/p>\n\n\n\n
      Wenn die TUI nur:<\/p>\n\n\n\n
      Processing\nCompleted\n<\/code><\/pre>\n\n\n\n
      kennt, kann sie Retry und Resume nicht sinnvoll darstellen.<\/p>\n\n\n\n
      Fehlerbehandlung beeinflusst deshalb:<\/p>\n\n\n\n
      Data Model\nState Model\nAPI Layer\nPersistence\nTUI\nMachine Output\nTests\n<\/code><\/pre>\n\n\n\n
      Sie ist Architektur.<\/p>\n\n\n\n
      \n\n\n\n
      Fehlerf\u00e4lle sollten zuerst modelliert werden<\/h1>\n\n\n\n
      Bei kritischer Logik lohnt sich eine kleine \u00dcbung.<\/p>\n\n\n\n
      Vor der Implementierung eine Tabelle erstellen:<\/p>\n\n\n\n
      Situation<\/th>Retry?<\/th>Zustand bekannt?<\/th>Resume?<\/th><\/tr><\/thead>
      200<\/td>nein<\/td>ja<\/td>\u2013<\/td><\/tr>
      429<\/td>ja<\/td>ja<\/td>ja<\/td><\/tr>
      503<\/td>ja<\/td>meist<\/td>ja<\/td><\/tr>
      403<\/td>nein<\/td>ja<\/td>nach Korrektur<\/td><\/tr>
      Timeout nach Request<\/td>eventuell<\/td>nein<\/td>abh\u00e4ngig von Idempotenz<\/td><\/tr>
      Partial Batch<\/td>teilweise<\/td>ja<\/td>ja<\/td><\/tr>
      Prozessabbruch<\/td>nein<\/td>teilweise<\/td>ja<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      Pl\u00f6tzlich werden Architekturfragen sichtbar, bevor sie Bugs werden.<\/p>\n\n\n\n
      \n\n\n\n
      Fehlerpfade brauchen Tests<\/h1>\n\n\n\n
      Der Happy Path sollte nat\u00fcrlich getestet werden.<\/p>\n\n\n\n
      Aber bei einem zuverl\u00e4ssigen Tool sind diese Tests mindestens genauso interessant:<\/p>\n\n\n\n
      429\n\u2192 Retry\n\u2192 Success\n<\/code><\/pre>\n\n\n\n
      500\n\u2192 Retry\n\u2192 Retry\n\u2192 Exhausted\n<\/code><\/pre>\n\n\n\n
      Batch:\n19 Success\n1 Failure\n<\/code><\/pre>\n\n\n\n
      20 Requests\n19 Responses\n<\/code><\/pre>\n\n\n\n
      Operation erfolgreich\nCheckpoint-Schreiben schl\u00e4gt fehl\n<\/code><\/pre>\n\n\n\n
      Resume\n\u2192 Failed ID wird erneut verarbeitet\n<\/code><\/pre>\n\n\n\n
      Verification\n\u2192 Remaining > 0\n<\/code><\/pre>\n\n\n\n
      Das sind die F\u00e4lle, die Architekturfehler sichtbar machen.<\/p>\n\n\n\n
      \n\n\n\n
      Chaos im Kleinen<\/h1>\n\n\n\n
      Man braucht daf\u00fcr kein gro\u00dfes Chaos-Engineering-System.<\/p>\n\n\n\n
      Schon gezielte simulierte Fehler sind wertvoll.<\/p>\n\n\n\n
      Beispielsweise:<\/p>\n\n\n\n
      Was passiert, wenn Request Nummer 7 fehlschl\u00e4gt?\n<\/code><\/pre>\n\n\n\n
      Oder:<\/p>\n\n\n\n
      Was passiert, wenn nach Batch 3 der Prozess beendet wird?\n<\/code><\/pre>\n\n\n\n
      Oder:<\/p>\n\n\n\n
      Was passiert, wenn die Verification andere Werte findet?\n<\/code><\/pre>\n\n\n\n
      Diese Fragen testen nicht nur Code.<\/p>\n\n\n\n
      Sie testen das Modell des Systems.<\/p>\n\n\n\n
      \n\n\n\n
      Der Happy Path versteckt schlechte Architektur<\/h1>\n\n\n\n
      Das ist vielleicht die wichtigste Beobachtung.<\/p>\n\n\n\n
      Viele strukturelle Fehler sind im Happy Path unsichtbar.<\/p>\n\n\n\n
      Wenn alles funktioniert:<\/p>\n\n\n\n
      Request\n\u2193\nSuccess\n\u2193\nRequest\n\u2193\nSuccess\n\u2193\nDone\n<\/code><\/pre>\n\n\n\n
      braucht man weder:<\/p>\n\n\n\n
        \n
      • Retry-State<\/li>\n\n\n\n
      • Failed IDs<\/li>\n\n\n\n
      • Checkpoints<\/li>\n\n\n\n
      • Resume<\/li>\n\n\n\n
      • Verification<\/li>\n\n\n\n
      • Unknown State<\/li>\n<\/ul>\n\n\n\n
        Erst Fehlerf\u00e4lle zwingen das System, seine tats\u00e4chliche Semantik offenzulegen.<\/p>\n\n\n\n
        Deshalb sind sie so wertvoll.<\/p>\n\n\n\n
        \n\n\n\n
        Reliability ist kein einzelnes Feature<\/h1>\n\n\n\n
        Man kann nicht einfach sagen:<\/p>\n\n\n\n
        Feature:\nRobust Error Handling \u2713\n<\/code><\/pre>\n\n\n\n
        Reliability entsteht aus mehreren Eigenschaften:<\/p>\n\n\n\n
        klare Fehlerklassifikation\n+\nbegrenztes Retry\n+\nBackoff\n+\nIdempotenz\n+\nPartial-Failure-Modell\n+\nCheckpoints\n+\nResume\n+\nVerification\n+\npr\u00e4zise Resultate\n+\nTests\n<\/code><\/pre>\n\n\n\n
        Keine davon allein macht ein System zuverl\u00e4ssig.<\/p>\n\n\n\n
        Zusammen ergeben sie ein belastbares Verhalten.<\/p>\n\n\n\n
        \n\n\n\n
        Ein robustes Verarbeitungsmodell<\/h1>\n\n\n\n
        F\u00fcr viele Batch-Tools l\u00e4sst sich der Ablauf ungef\u00e4hr so zusammenfassen:<\/p>\n\n\n\n
        DISCOVER\n   \u2193\nBUILD WORK QUEUE\n   \u2193\nPROCESS BATCH\n   \u2193\nCLASSIFY RESULTS\n   \u251c\u2500\u2500 Succeeded\n   \u251c\u2500\u2500 Retryable\n   \u251c\u2500\u2500 Failed\n   \u2514\u2500\u2500 Unknown\n   \u2193\nRETRY SAFE OPERATIONS\n   \u2193\nCOMMIT CHECKPOINT\n   \u2193\nNEXT BATCH\n   \u2193\nVERIFY FINAL STATE\n   \u2193\nREPORT RESULT\n<\/code><\/pre>\n\n\n\n
        Das ist deutlich mehr als:<\/p>\n\n\n\n
        foreach item\n    try\n        process\n    catch\n        retry\n<\/code><\/pre>\n\n\n\n
        Aber genau diese zus\u00e4tzlichen Schritte machen den Unterschied.<\/p>\n\n\n\n
        \n\n\n\n
        Das Interessante daran: Es gilt weit \u00fcber PowerShell hinaus<\/h1>\n\n\n\n
        Diese Konzepte sind nicht PowerShell-spezifisch.<\/p>\n\n\n\n
        Sie gelten f\u00fcr:<\/p>\n\n\n\n
          \n
        • REST-Clients<\/li>\n\n\n\n
        • Background Jobs<\/li>\n\n\n\n
        • Message Processing<\/li>\n\n\n\n
        • Datenmigrationen<\/li>\n\n\n\n
        • Synchronisationsdienste<\/li>\n\n\n\n
        • Importer<\/li>\n\n\n\n
        • Deployment Tools<\/li>\n\n\n\n
        • Batch-Verarbeitung<\/li>\n\n\n\n
        • Cloud-Automation<\/li>\n<\/ul>\n\n\n\n
          Die konkrete Syntax \u00e4ndert sich.<\/p>\n\n\n\n
          Die Fragen bleiben dieselben:<\/p>\n\n\n\n
          Was wurde versucht?\nWas war erfolgreich?\nWas ist fehlgeschlagen?\nWas ist unbekannt?\nWas darf wiederholt werden?\nWas wurde persistiert?\nWie kann weitergemacht werden?\nWie wissen wir, dass wir fertig sind?\n<\/code><\/pre>\n\n\n\n
          Wer diese Fragen beantworten kann, hat einen gro\u00dfen Teil des Reliability-Problems bereits verstanden.<\/p>\n\n\n\n
          \n\n\n\n
          Was ich bei einem neuen Tool heute zuerst definieren w\u00fcrde<\/h1>\n\n\n\n
          Noch bevor die aufwendige Fehlerbehandlung implementiert wird:<\/p>\n\n\n\n
          1. Was ist die atomare Arbeitseinheit?<\/strong><\/p>\n\n\n\n
          eine Nachricht\neine Datei\nein Datensatz\nein API-Request\n<\/code><\/pre>\n\n\n\n
          2. Was bedeutet Erfolg?<\/strong><\/p>\n\n\n\n
          Request angenommen?\nMutation best\u00e4tigt?\nEndzustand verifiziert?\n<\/code><\/pre>\n\n\n\n
          3. Ist die Operation idempotent?<\/strong><\/p>\n\n\n\n
          4. Welche Fehler sind retrybar?<\/strong><\/p>\n\n\n\n
          5. Welche Zust\u00e4nde k\u00f6nnen nach einem Abbruch existieren?<\/strong><\/p>\n\n\n\n
          6. Welche Informationen braucht Resume?<\/strong><\/p>\n\n\n\n
          7. Was muss ein Checkpoint speichern?<\/strong><\/p>\n\n\n\n
          8. Wie wird der Endzustand verifiziert?<\/strong><\/p>\n\n\n\n
          Wenn diese Fragen klar sind, wird die Implementierung deutlich einfacher.<\/p>\n\n\n\n
          \n\n\n\n
          Fazit<\/h1>\n\n\n\n
          Der Happy Path beweist, dass ein System unter idealen Bedingungen funktioniert.<\/p>\n\n\n\n
          Produktionsreife zeigt sich unter nicht idealen Bedingungen.<\/p>\n\n\n\n
          Nicht die Frage:<\/p>\n\n\n\n
          \n
          Funktioniert die API?<\/p>\n<\/blockquote>\n\n\n\n
          ist dann entscheidend.<\/p>\n\n\n\n
          Sondern:<\/p>\n\n\n\n
          \n
          Wissen wir nach einem Fehler noch, was tats\u00e4chlich passiert ist?<\/p>\n<\/blockquote>\n\n\n\n
          Ein robustes System unterscheidet deshalb zwischen:<\/p>\n\n\n\n
          Attempted\nSucceeded\nFailed\nRetryable\nUnknown\nVerified\n<\/code><\/pre>\n\n\n\n
          Es wiederholt Operationen nicht blind.<\/p>\n\n\n\n
          Es versteht Idempotenz.<\/p>\n\n\n\n
          Es persistiert best\u00e4tigten Fortschritt.<\/p>\n\n\n\n
          Es kann nach einem Abbruch weiterarbeiten.<\/p>\n\n\n\n
          Und es pr\u00fcft am Ende nicht nur, ob Requests erfolgreich waren, sondern ob der gew\u00fcnschte Zustand tats\u00e4chlich erreicht wurde.<\/p>\n\n\n\n
          Die wichtigste Erkenntnis dieser Serie lautet deshalb:<\/p>\n\n\n\n
          \n
          Fehlerbehandlung bedeutet nicht, Exceptions abzufangen. Sie bedeutet, auch nach einem teilweise gescheiterten Ablauf noch eindeutig zu wissen, in welchem Zustand sich das System befindet und wie es sicher weitergehen kann.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
          Genau dort endet der Happy Path.<\/p>\n\n\n\n
          Und dort beginnt Reliability.<\/p>\n","protected":false},"excerpt":{"rendered":"
          Software l\u00e4sst sich erstaunlich leicht demonstrieren. Man startet das Programm. Die Verbindung funktioniert. Die API antwortet. Alle Daten sind vorhanden. Jede Operation ist erfolgreich. Am Ende erscheint: Damit ist bewiesen, dass der Happy Path funktioniert. Mehr aber auch nicht. Produktionsreife beginnt bei einer anderen Frage: Was passiert, wenn die Operation nur teilweise funktioniert? Genau dort […]<\/p>\n","protected":false},"author":1,"featured_media":338,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,27,25,59],"tags":[],"class_list":["post-332","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automation","category-programming-principles","category-software-engineering","category-system-engineering"],"_links":{"self":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/332","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=332"}],"version-history":[{"count":1,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/332\/revisions"}],"predecessor-version":[{"id":333,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/332\/revisions\/333"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/media\/338"}],"wp:attachment":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=332"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=332"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=332"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}