8 сентября 2026 года вышли обновления Laravel: 12.69.2 и 13.31.0. В первой версии внесены три незначительных исправления, а вторая версия улучшает работу с очередями, Redis, Eloquent и HTTP-клиентом, а также добавляет несколько новых API. Эти обновления предназначены для текущих проектов и не требуют обязательного перехода с Laravel 12 на 13.
Два релиза с разным масштабом
Laravel 12.69.2 и 13.31.0 вышли в один день, но решают разные задачи. В официальных примечаниях к Laravel 12.69.2 перечислены три изменения, тогда как Laravel 13.31.0 затрагивает значительно больше компонентов фреймворка. Оба релиза опубликованы 8 сентября 2026 года.
| Версия | Основной характер изменений | Кому обратить внимание |
| 12.69.2 | Настройка Cloud-очередей и корректировка типов callback-функций | Проектам на ветке 12.x, особенно с управляемыми очередями Laravel Cloud |
| 13.31.0 | Исправления очередей, Redis Cluster, Eloquent, HTTP-клиента, авторизации и почты | Проектам на 13.x, использующим фоновые задания, сложные отношения моделей и внешние сервисы |
Номер 13.31.0 не означает выход Laravel 13 как новой мажорной версии: это очередной релиз уже существующей ветки 13.x. Аналогично 12.69.2 не требует смены мажорной версии приложения.
Laravel 12.69.2 — Cloud и типы callback-функций
В Laravel 12.69.2 изменены настройки управляемых очередей Cloud и две аннотации типов. Релиз не добавляет новых возможностей для обычного HTTP-приложения и не содержит объявленного изменения публичного API, требующего переписывания пользовательского кода.
Поведение воркера при нехватке памяти
Для управляемых очередей Laravel Cloud значение Worker::$memoryExceededExitCode теперь по умолчанию устанавливается в null. Ранее пользовательская настройка кода завершения могла приводить к тому, что при превышении лимита памяти воркер завершался без ожидаемых уведомлений. Изменение возвращает управление стандартному механизму завершения в Cloud и сопровождается тестом, проверяющим новое значение. Изменение #61432.
Практический смысл есть прежде всего для приложений, где воркеры обрабатывают тяжёлые задания: генерацию отчётов, обработку файлов или большие очереди. После обновления стоит проверить собственные обработчики завершения воркеров и мониторинг ошибок памяти, если они зависят от кода выхода процесса.
Уточнение сигнатур
Два других изменения касаются описания возвращаемого типа замыканий: withFreshQueryLog() и askWithCompletion(). В типовых аннотациях callback-функций добавлены необходимые скобки. Это корректировка представления типов, а не новая логика построения SQL-запросов или работы консольного автодополнения. Она полезна для инструментов статического анализа и IDE, которые читают сигнатуры Laravel. Примечания к релизу.
Laravel 13.31.0 — точнее работа с очередями
В Laravel 13.31.0 расширены средства наблюдения за очередями и исправлены ошибки, которые могли влиять на выполнение заданий. Наиболее существенные изменения касаются суммарного размера очереди, прерываемых jobs, нескольких одновременных лимитов и Redis Cluster.
Суммарный размер и прерывание заданий
Новый метод Queue::totalSize() возвращает общее количество заданий в соединении, включая ожидающие, отложенные и зарезервированные. Ранее для такого показателя приходилось складывать результаты трёх отдельных методов. Реализация поддерживает соединения Database, Redis и Cloud, а также fake-драйвер для тестов. Для database-очереди это позволяет получать итог без нескольких отдельных запросов. PR #61373.
use Illuminate\Support\Facades\Queue;
$total = Queue::totalSize();Также добавлено событие JobInterrupted. Оно отправляется, когда сигнал прерывания получает задание, реализующее Interruptible. В отличие от WorkerInterrupted, которое может возникать при сигнале даже без выполняющегося задания, новое событие позволяет реагировать именно на прерывание конкретной job. Это удобно для собственного логирования и освобождения ресурсов. PR #61412.
Исправлен учёт нескольких лимитов
Middleware RateLimited раньше мог увеличивать счётчики уже проверенных лимитов, даже если следующий лимит запрещал выполнение задания. Например, исчерпание лимита одного арендатора могло расходовать общий лимит для остальных, хотя job фактически не выполнялась. Теперь сначала проверяются все ограничения, и только после этого учитывается использование. PR #61449.
Для систем с глобальными и пользовательскими квотами это устраняет источник ложных блокировок. После обновления полезно проверить сценарии, в которых одно задание одновременно подчиняется нескольким rate limiters.
Redis Cluster и пакетная постановка jobs
Исправлены две проблемы драйвера очередей при использовании phpredis с Redis Cluster. Первая могла приводить к потере пакетно добавляемых заданий: транзакция MULTI не привязывалась к нужному узлу кластера, а Bus::batch() при этом мог сообщать об успешной постановке. Новая реализация использует Lua-скрипт для одного hash slot и обрабатывает пакеты частями по 1000 заданий. Вторая проблема касалась перечисления очередей: вместо KEYS на кластерных соединениях используется обход master-узлов через SCAN. PR #61198.
В этом же релизе исправлена передача command_retries в кластерные соединения phpredis и повтор команд при некоторых сбросах соединения, представленных как предупреждения. Это особенно актуально для приложений, работающих с несколькими Redis-узлами или управляемыми кластерными сервисами.
Eloquent — исправления запросов и отношений
Laravel 13.31.0 содержит несколько исправлений Eloquent, которые важнее обычных косметических изменений: они касаются корректности SQL и области действия операций над данными.
wherePivot() больше не теряет замыкание
Исправлена ошибка, при которой ограничение, заданное через замыкание в wherePivot(), учитывалось в основном запросе отношения, но не сохранялось для последующих операций с pivot-таблицей. В результате detach(), sync() и updateExistingPivot() могли работать с записями вне ожидаемого ограничения. Теперь условие сохраняется и повторно применяется при построении pivot-запроса. PR #61488.
Это изменение стоит проверить в проектах, где многие-ко-многим отношения используют дополнительные ограничения, например по арендатору, статусу или типу связи. Ошибка могла приводить не только к неверной выборке, но и к изменению либо удалению лишних строк связующей таблицы.
Алиасы таблиц и прямые подключения
Для моделей с SoftDeletes исправлена квалификация столбца deleted_at, когда таблица имеет алиас. Раньше запрос вида User::from('users as u') мог использовать users.deleted_at вместо u.deleted_at; в коррелированных подзапросах это иногда давало неверный результат без ошибки SQL. Теперь Eloquent учитывает алиас при построении условия мягкого удаления. PR #61456.
Другой фикс сохраняет суффикс ::direct у подключения во время миграций. Это предотвращает ситуацию, когда миграция выполняется через прямое соединение PostgreSQL, а вызванная внутри неё Eloquent-модель неожиданно переходит на обычное соединение. Для схем с transaction pooler такое различие влияет на видимость созданных таблиц и принадлежность операций одной транзакции. PR #61435.
chaperone() для пользовательских pivot-моделей
В отношении BelongsToMany появилась поддержка chaperone() для пользовательских pivot-моделей. Она позволяет автоматически связывать pivot-объект с уже загруженными родительской и связанной моделями, чтобы не выполнять повторную загрузку этих моделей из базы. Без пользовательской pivot-модели вызов не меняет поведение. PR #61152.
Дополнительно исправлено применение limit() и offset() в lazy() и lazyById(), а также наследование атрибутов UsePolicy и UseEloquentBuilder от родительских классов. Эти изменения полезны для приложений с большими выборками и базовыми классами моделей.
HTTP-клиент, авторизация и почта
В Laravel 13.31.0 устранена временная утечка памяти в HTTP-клиенте, исправлена проверка remember-cookie и скорректировано сохранение идентификатора письма при отправке через Resend.
HTTP-клиент больше не удерживает ненужные ссылки на PendingRequest через цикл замыканий. В прежней реализации это могло сохранять в памяти данные ответов Guzzle при большом количестве последовательных запросов, например при загрузке изображений в цикле. Исправление уменьшает риск накопления памяти в длительно работающих заданиях. PR #61438.
В авторизации ветка 13.x получила исправления проверки хеша пароля в remember-cookie и обработки случая, когда cookie не соответствует ни одному пользователю. Это перенос уже внесённых в ветку 12.x исправлений, а не новая функция авторизации. Также исправлены сохранение ID письма и заголовка X-Resend-Email-ID в ResendTransport, что важно для сопоставления событий отправки с доставкой. PR #61476.
Среди остальных изменений — корректировка генерации URL маршрутов в отдельных случаях, восстановление передачи context в конкурентные процессы, исправление вложенных отложенных callback-функций, новый devServerUrl() для Vite и проверки once в fake-объектах почты и уведомлений. Добавлено и исправление совместимости ArraySessionHandler с требованием будущего PHP 9.0 к методу create_sid(). Эти пункты не означают, что PHP 9.0 стал обязательным для Laravel 13.
Практический контекст
Обновление до версии Laravel 12.69.2 рекомендуется проводить как стандартное обновление текущей ветки, особенно если вы работаете с Cloud-очередями. Версия Laravel 13.31.0 обладает более высоким практическим значением для приложений, использующих Redis Cluster, сложные pivot-операции и большой объем фоновой HTTP-обработки. В этой версии исправлены ошибки, влияющие на корректность данных и стабильность выполнения задач.
Для проекта, уже работающего на соответствующей ветке, обновление можно выполнить после проверки ограничений в composer.json и резервного копирования:
composer update laravel/framework --with-all-dependencies
php artisan testКоманда обновляет фреймворк в пределах разрешённых Composer версий; она не должна использоваться как способ принудительно перейти с Laravel 12 на 13. Перед развёртыванием стоит проверить совместимость сторонних пакетов, миграции и тесты критичных сценариев очередей.
По официальной политике поддержки, Laravel 12 поддерживает PHP 8.2–8.5 и получает исправления безопасности до 24 февраля 2027 года. Для Laravel 13 указан PHP 8.3–8.5, а окончание поддержки безопасности запланировано на 17 марта 2028 года. Поэтому переход между мажорными версиями следует планировать отдельно от установки этих исправлений.
