3f6f0ef163
spieler+macher pro Tag, geerdet in den realen Commits; data.json via @mana/devlog-gen backfill. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
13 lines
1,005 B
Markdown
13 lines
1,005 B
Markdown
---
|
|
date: 2026-05-21
|
|
day: 6
|
|
view: macher
|
|
weekday: Donnerstag
|
|
commits: 1
|
|
review: auto
|
|
---
|
|
# Donnerstag, 2026-05-21 — Tag 6 (Macher-Sicht)
|
|
|
|
Ein Commit, aber +253 LoC und v1.8.0: `RefreshFailurePolicy` plus Diagnostik (`53d5dca`). Bislang war Token-Refresh binär — er klappt oder der Nutzer fliegt raus. Das ist falsch, wenn der Refresh nur an einem vorübergehenden Netzwerkfehler scheitert: ein DNS-Hänger oder ein 503 sollte nicht denselben Logout auslösen wie ein vom Server invalidierter Refresh-Token (401/403).
|
|
|
|
Die neue Policy trennt diese Fälle: transiente Fehler → erneut versuchen / Session halten, definitive Auth-Fehler → sauberer Logout. Dazu kommt Diagnostik, die festhält, *warum* ein Refresh fehlschlug, statt es im OSLog-Rauschen zu verlieren. Getestet wird das über `MockURLProtocol` (neu in den Tests) gegen die State-Machine, nicht gegen echtes Netz — wie Invariante 8 es verlangt. Die Resilience-Tests in `AuthClientGuestAndResilienceTests` decken die Verzweigungen ab.
|