Версия 1.5.1 — 2026-06-03

Хотфикс для деплоя на свежую БД: миграции падали из-за порядка запуска.

Исправлено

Миграции на свежей БД падали с «relation "audits" does not exist»

При первом разворачивании на чистую базу Laravel запускает миграции в порядке timestamp'а файла. Миграция 2026_04_10_120000_grant_super_admin_permissions_and_assign_to_sidorenko идёт раньше, чем 2026_05_07_165231_create_audits_table.

Первая раздаёт супер-админу все права через Spatie syncPermissions(), что стреляет событие PermissionAttached. Наш App\Providers\AuditEventServiceProvider это событие слушает и пытается записать в таблицу audits через ActionLogger::record() → Audit::create(...). На свежей БД таблица ещё не создана (она появится только следующей майской миграцией) → SQLSTATE[42P01]: relation "audits" does not exist → миграция падает, деплой не проходит.

На существующем dev/prod это не воспроизводилось, потому что миграции применялись постепенно и таблица audits была создана раньше, чем раздавались новые права.

Фикс — в App\Services\ActionLogger: перед Audit::create(...) проверяется, существует ли таблица audits. Если нет — запись тихо скипается. Результат проверки кешируется в статическом свойстве на жизнь процесса, чтобы не делать лишний запрос на каждое событие.

private static ?bool $auditsTableExists = null;

private function record(...): void {
    if (! $this->auditsTableExists()) {
        return;
    }
    Audit::create([...]);
}

private function auditsTableExists(): bool {
    if (self::$auditsTableExists === null) {
        try { self::$auditsTableExists = Schema::hasTable('audits'); }
        catch (\Throwable) { self::$auditsTableExists = false; }
    }
    return self::$auditsTableExists;
}

Эффект:

• На свежей БД: миграция апреля раздаёт права, audit-события стреляют, record() тихо скипает, миграция мая создаёт таблицу audits, дальше всё пишется как обычно.
• На существующем prod/dev: первая же проверка Schema::hasTable('audits') вернёт true, закешируется, поведение неизменно.
• При любой другой проблеме со схемой (например, временно недоступная БД при boot'е) — Throwable ловится, лог продолжает жить.

Сценарий, где из-за этого фикса будут потеряны audit-записи — только тот самый интервал «между раздачей прав в первой миграции и созданием таблицы во второй» при первом развёртывании. Это нескольких секунд интервал на чистой инсталляции, никаких полезных записей там быть не может.