Skip to content

fix(deploy): 429-Beweis im ganzen Log suchen + gescheiterten Slot stoppen - #81

Merged
daniel-marthaler merged 1 commit into
masterfrom
fix/vault-429-erkennung-und-zombie-slot
Aug 22, 2026
Merged

fix(deploy): 429-Beweis im ganzen Log suchen + gescheiterten Slot stoppen#81
daniel-marthaler merged 1 commit into
masterfrom
fix/vault-429-erkennung-und-zombie-slot

Conversation

@daniel-marthaler

Copy link
Copy Markdown
Collaborator

Anlass

Drei transiente Vaultwarden-Fehler bei Deploy-Healthchecks in vier Tagen (guild 1.372.0 und app snapshot-dev am 21.08., schuetu am 18.08.). Root-Cause-Analyse siehe Commit-Message; Kurzfassung:

  • Ein nach Deploy-Abbruch stehen gelassener Slot-Container (restart: always) crashloopt unbegrenzt weiter und macht pro Boot einen Vaultwarden-Login. Der Login-Rate-Limiter (Default: Burst 10, Refill 1/60s, EIN Bucket fuer alle Clients, weil alle als dieselbe NAT-IP ankommen) bleibt dadurch dauerhaft leer — parallele Deploys scheitern mit HTTP 429 beim Environment-Post-Processing (Fail-fast).
  • Der vorhandene 429-Retry (Karte 422) zuendete nie, weil docker logs --tail 60 nur die zwei Stacktraces des Fail-fast-Abbruchs erwischt — die beweisende WARN-Zeile mit HTTP 429 liegt oberhalb des Fensters.

Aenderungen

  1. 429-Erkennung: Log-Fenster fuer Diagnose und HEALTHCHECK_SAH_429 von 60 auf 300 Zeilen erhoeht (Anzeige bleibt bei 60 Zeilen).
  2. Zombie-Stopp: Nach endgueltig fehlgeschlagenem Healthcheck (mit oder ohne Retry) wird der gescheiterte neue Slot per docker stop angehalten. Gefahrlos: Traffic wurde nie umgeschaltet, der naechste Deploy macht ohnehin force-recreate.

Belege (21.08., UTC)

  • 21:50:24 app-Deploy bricht ab (Flyway countdown already exists), Slot bleibt als Zombie im Crashloop
  • 21:51:24 erster 429 im Vaultwarden-Log, Bucket bleibt danach durch den Zombie leer
  • 21:59:26 app-int-green: WARN VaultwardenClient: Vaultwarden riegelt mit einem Rate-Limit ab (token-Endpoint HTTP 429 ...)
  • 22:00:14 guild-int-blue: dieselbe WARN — beide Deploys scheitern, in beiden Run-Logs fehlt HTTP 429 im tail-60-Dump komplett (Retry-Bedingung nie erfuellt)

🤖 Generated with Claude Code

…ppen

Vorfaelle 21.08.2026 (guild 1.372.0 + app snapshot-dev):

1) Der Karte-422-Retry zuendete nie: docker logs --tail 60 zeigte nur die
   beiden ~30-zeiligen Stacktraces des Fail-fast-Abbruchs, die WARN-Zeile
   'Vaultwarden riegelt mit einem Rate-Limit ab (token-Endpoint HTTP 429...)'
   lag OBERHALB des Fensters. Jetzt werden 300 Zeilen geholt; angezeigt
   werden weiterhin 60, Diagnose und 429-Erkennung lesen alle 300.

2) Der gescheiterte neue Slot (restart: always) blieb nach dem Abbruch als
   Zombie im Crashloop stehen und machte pro Boot einen Vaultwarden-Login.
   Der geteilte Login-Rate-Limit-Bucket (alle Clients = eine NAT-IP, Refill
   1/min = Docker-Restart-Backoff-Rate) blieb dadurch dauerhaft leer und
   liess PARALLELE Deploys mit HTTP 429 scheitern. Nach endgueltig
   fehlgeschlagenem Healthcheck wird der Slot jetzt gestoppt.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@daniel-marthaler
daniel-marthaler merged commit 4c93fcd into master Aug 22, 2026
1 check passed
@daniel-marthaler
daniel-marthaler deleted the fix/vault-429-erkennung-und-zombie-slot branch August 22, 2026 09:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant