Der Commit 1536a3b hatte den Test „reply, approve-preview und start-build warten länger als die übrigen
Pult-Aktionen“ gelöscht. Der neue Test prüft gegen den heutigen Code (ACTION_TIMEOUT_MS 65 s,
REQUEST_TIMEOUT_MS 20 s, Optionen timeoutMs / actionTimeoutMs) mit den Uhren von node:test statt echter
Wartezeit: keine Abhängigkeit von der Last, Grenzen auf die Millisekunde (eine Millisekunde vor der Frist
läuft der Abruf, mit ihr endet er). Die drei langsamen Aktionen nehmen eine Antwort zwischen kurzer und langer
Frist an, claim/sent/discard/done/paste und das Lesen enden mit der kurzen Frist (DOWN_TEXT, status 0, Signal
abgebrochen), ein hängender Abruf endet nach der langen Frist. Derselbe Ablauf mit Standard- und mit
eingespeisten Fristen; ein zweiter Test pinnt, dass auch der Wiederholungsversuch nach einer 401 die Frist
der Aktion behält.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Die Unsicherheits-Meldung (D14) galt nur für status 0. Eine Fehlerseite des Proxys (502, 504) zeigte
„Der Hustler-Dienst ist gerade nicht erreichbar.“, obwohl der Dienst weiterarbeitet und die Mail schon
hinausgegangen sein kann. workersApi.js exportiert UNCERTAIN_STATUS = [0, 502, 504]; actionErrorText
prüft ihn (503, 429, 4xx und 500 bleiben unverändert, ebenso ein Satz des Dienstes unter 502).
ACTION_TIMEOUT_MS steigt auf 65 s, damit der Client nicht gleichauf mit dem proxy_read_timeout (60 s)
läuft und ein 504 zuerst ankommt. Tests über createWorkersApi mit Fehlerseiten für alle acht Aktionen.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Nur ein HTTP-Code ab 400 von Appwrite startet die 2-Minuten-Sperre. Übertragungsfehler
(TypeError, SDK-Fehler mit code 0, Fehler ohne Code), auch wenn sie erst nach der
Zeitgrenze eintreffen, geben die Dienst-Meldung (status 0) und sperren nichts: nach dem
Aufwachen aus dem Ruhezustand erholt sich das Hochhaus mit dem nächsten Takt. Eine späte
echte Ablehnung (etwa 429) sperrt weiter.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Endprüfung P2. Ein Abruf auf toter Verbindung (Rechner im Ruhezustand, Netzwechsel) blieb offen, und die
Feed-Schleifen laufen mit einem Abruf je Schleife: die Seite stand still und zeigte veraltete Daten als aktuell.
createWorkersApi bricht jetzt jeden Versuch (JWT holen, senden, Antwort lesen) nach 20 s mit "Der Hustler-Dienst ist
gerade nicht erreichbar." (status 0) ab, auch wenn fetch oder createJWT das Signal nicht beachten.
Außerdem erzwang jede 401-Antwort ein frisches createJWT, bei dauerhaftem 401 etwa 16 bis 20 Mal je Minute und Tab.
Appwrite begrenzt createJWT je Nutzer; das Limit hätte auch Serverpuls, Finanzen und Vorschauen gesperrt. Nach einer
401-Folge (frisches JWT wird ebenfalls abgelehnt oder lässt sich nicht erzeugen) gibt es 2 Minuten lang kein frisches
JWT mehr, die Meldung "Anmeldung abgelaufen" bleibt; Erfolg hebt die Sperre auf.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
