Laravel 13.42 bringt typisiertes UUID- und ULID-Lesen sowie ein Event für fehlgeschlagene Migrationen

Laravel 13.42 ist am 10. November 2026 ohne großes Aufsehen erschienen, bringt aber vier Ergänzungen, die Teams mit Produktivanwendungen schnell bemerken werden: typisiertes Lesen von UUIDs und ULIDs aus Request-Daten, ein Event, das bei einer fehlgeschlagenen Migration ausgelöst wird, und einen expliziten Grund für jede übersprungene geplante Aufgabe. Diese Minor-Version des 13.x-Zweigs bringt keine inkompatiblen Änderungen mit sich.

#UUID oder ULID aus dem Request lesen, ohne Wiederholcode

Bisher musste man für eine UUID aus den Request-Daten Uuid::fromString() aufrufen und das Fehlen eines Werts von Hand prüfen. Die neuen Methoden uuid() und ulid() im Trait InteractsWithData erledigen beides in einem Aufruf und stehen auf Request, Fluent, ValidatedInput, UriQueryString, ComponentAttributeBag und CommandInput zur Verfügung.

$request->uuid('order_id'); // Ramsey\Uuid\UuidInterface|null
$request->ulid('order_id'); // Symfony\Component\Uid\Ulid|null

$request->safe()->uuid('order_id');

Eine fehlende oder leere Eingabe liefert in beiden Fällen null; ein ungültiger Wert löst eine Ausnahme aus, statt eine fehlerhafte Zeichenkette durchzulassen. Bei ulid() entschied sich das Team bewusst für new Ulid($value) statt Ulid::fromString(), da Letztere auch andere Formate akzeptiert und eine UUID stillschweigend in eine andere ULID umwandeln könnte.

#Ein Event, um auf fehlgeschlagene Migrationen zu reagieren

Das Event MigrationFailed umschließt jede Migration mit einem try/catch-Block: Bei einem Fehler löst das Event aus, und die Ausnahme nimmt danach ihren normalen Verlauf. Der Autor der Funktion verwies auf ALTER-Anweisungen unter MySQL, die sich nicht zurückrollen lassen: Ein fehlgeschlagenes Deployment kann die Datenbank teilweise verändert zurücklassen, und dieses Signal erlaubt es, zu reagieren, bevor es jemand von Hand entdeckt.

Unter MySQL hinterlässt eine ALTER-Anweisung, die mitten in der Migration fehlschlägt, die Datenbank teilweise verändert und ohne Rollback-Möglichkeit — das neue Event MigrationFailed gibt Teams endlich einen Anknüpfungspunkt, um sofort zu reagieren.

Event::listen(function (MigrationFailed $event) {
    Artisan::call('down');
    Queue::pauseAll();

    Log::channel('slack')->critical("Migration [{$event->name}] failed on ".config('app.name'), [
        'exception' => $event->exception->getMessage(),
    ]);
});

#Keine Eile, aber gut zu kennen

Nichts an dieser Version erzwingt ein sofortiges Update: Es handelt sich um additive Funktionen, nicht um Sicherheitskorrekturen. Der übliche Befehl genügt, um sie in einem bestehenden Projekt auf dem 13.x-Zweig zu nutzen.

composer update laravel/framework
php artisan --version

#Dieselbe Sorgfalt wie bei der Runtime-Wartung

Diese Art von Minor-Release spiegelt eine Disziplin wider, die sich auch auf der Runtime-Seite zeigt: Node.js‘ Sicherheitsveröffentlichung vom 11. November erinnert daran, dass die laufende Pflege eines Backend-Stacks sich nicht auf Sicherheitspatches beschränkt, sondern auch solche kleinen Annehmlichkeiten umfasst, die über die Zeit die technische Schuld abtragen. Teams, die bereits die Warteschlangen-Überwachung aus Version 13.40 verfolgt haben, erkennen hier dieselbe Instrumentierungslogik, diesmal angewandt auf Migrationen und den Scheduler.

#Was zu beachten bleibt

Laravel 13.42 ist kein großer Meilenstein, doch seine vier Ergänzungen — typisiertes UUID- und ULID-Lesen, ein Event für fehlgeschlagene Migrationen, ein Grund für übersprungene Aufgaben — beheben jeweils ein konkretes Ärgernis, das in der Produktion bereits aufgetreten ist. Ein risikoarmes Update, das sich für den nächsten Wartungszyklus einplanen lässt, statt es eilig nachzuziehen.

Zum Weiterlesen: Die vollständige Liste der Pull Requests findet sich im Repository laravel/framework auf GitHub.