Eine zeitliche Grenze hebelt --tries nicht bloss fuer Rueckstellungen aus,
sondern ganz: Worker::markJobAsFailedIfWillExceedMaxAttempts prueft die
Versuchszahl ausdruecklich nur if (! $job->retryUntil()). Damit galten die drei
Versuche seit dem Takt NIRGENDS mehr — auch nicht auf der Direktspur und auch
nicht bei ausgeschaltetem Notschalter.
Eine Mail, die aus echtem Grund wirft (SMTP tot, PDF-Rendern kippt), wurde
dadurch sechs Stunden lang wiederholt statt nach drei Versuchen abgelegt, und
ohne Pause, weil der Arbeiter ohne --backoff laeuft. Ihr Fehler stand sechs
Stunden lang nicht in failed_jobs, und auf der Direktspur haette eine einzige
giftige Mail sechs Stunden lang die Kennwort-Zuruecksetzungen blockiert, sobald
Aufgabe 4 den Arbeiter in Prioritaetsreihenfolge lesen laesst.
retryUntil() haengt jetzt an derselben Bedingung wie die Drossel, beide lesen
gedrosselteSpur(). Vorher wird die Elternklasse gefragt: SendQueuedMailable
reicht an die Mailklasse weiter, und die Ueberschreibung nahm das still weg.
Dazu zwei kleinere Punkte aus derselben Durchsicht: der Kopfkommentar behauptete
weiter, eine middleware() auf der Mailklasse lese niemand — widerlegt am
Vendor-Code, jetzt steht der echte Grund dort. Und (int) Settings::get() ergab
auch ohne eingetipptes 0 eine Null (gespeicherte null, nichtnumerischer Wert);
eine Untergrenze steht jetzt an der Lesestelle, an der der Verlust passiert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0475aad7b0