Inertia SSR: чому падає лише 404 сторінка

Після виправлення Ziggy integration усе виглядало добре. Звичайні public pages працювали, UK/EN navigation була чистою, а в admin більше не було routing errors.

Але в Laravel log час від часу все одно залишався Inertia\Ssr\SsrException.

Найдивніше було те, що на звичайній сторінці я вже не могла його відтворити.

Це третя частина мого routing-кейсу. Спочатку я розібрала logical route names і localized URLs, а потім - як зробити Ziggy однаковим для Blade, Vue та Inertia SSR.

На цьому етапі normal routing flow уже працював. Залишився один дуже конкретний edge case - 404 page.

Помилка виглядала так, ніби Ziggy просто не знає route posts.index. Але це не сходилося з тим, що я бачила в application.

Route працював у browser, logical Ziggy configuration уже була підключена, а звичайні сторінки SSR-renderилися нормально.

Тому я вирішила не правити routing code навмання, а спочатку точно визначити, який request створює exception.

Схожу різницю між browser та SSR я вже бачила раніше, коли meta tags були в браузері, але не потрапляли в HTML під час Inertia SSR. Тому цього разу я одразу розділяла browser flow і server-side rendering.

Першою я відкрила звичайну public page. Не error page і не спеціальний тестовий URL - просто сторінку, яка повинна працювати.

Після request я прочитала тільки нові рядки log.

Нічого не з’явилося.

Наступний крок був простим: не чекати, поки exception випадково повториться, а створити контрольований 404.

Я відкрила гарантовано неіснуючий URL і після цього знову перевірила тільки рядки після нашої мітки.

Цього разу помилка з’явилася одразу.

Після контрольного 404 stack trace вже не був просто старим шумом у log. Я точно знала, який request його створив.

Стек проходив через ziggy-js і далі в compiled PublicLayout.

У самому layout помилка проявлялася на route, який використовував public header.

На цьому місці було дуже легко вирішити, що проблема в Header.vue або в самому route name.

Але я вже підозрювала інше: error page міг отримувати не ту Ziggy configuration, яку отримує normal page.

Тому спочатку я перевірила backend напряму через Laravel container.

• posts.index існує в Laravel.

• LogicalZiggy container binding працює.

• posts.index присутній у Ziggy configuration.

• Normal public SSR request не створює помилки.

• Browser navigation працює.

• Controlled 404 стабільно відтворює SSR exception.

Після цього область пошуку стала набагато меншою.

Проблема вже не виглядала як загальний Ziggy bug і не виглядала як проблема route registration.

Вона була специфічною саме для SSR error-response flow: normal Inertia page і 404 error page поводилися по-різному.

Stack trace показував на PublicLayout і Header, але це ще не означало, що причина знаходиться саме там.

Header робив звичайний route('posts.index'), який нормально працював у normal page context.

Якби я додала fallback або special case для 404, це могло б просто приховати проблему з routing context.

На цьому етапі найбільш логічним поясненням був інший або неповний набір Inertia props під час rendering error page.

Normal SSR отримував Ziggy configuration, з якою posts.index працював. Controlled 404 стабільно падав на тому самому route.

Цього було достатньо, щоб локалізувати проблему до error-page SSR context і не продовжувати змінювати основну localization integration.

• Поставити log marker перед перевіркою.

• Виконати один normal request.

• Переконатися, що він не створює нових errors.

• Виконати один контрольований error request.

• Читати тільки нові log lines.

• Перевірити route безпосередньо в Laravel.

• Перевірити Ziggy configuration через container.

• Не змінювати component, поки не зрозуміло, чи проблема справді в ньому.

• Окремо порівняти normal page context та error-page context.

Команди тут були дуже простими, але саме вони прибрали більшу частину плутанини.

Коли я дивилася просто останні кілька сотень рядків, там змішувалися старі й нові SSR errors.

Після marker кожен request уже мав конкретний результат: або він додав новий exception, або ні.

До цього моменту основна integration уже проходила normal public та admin smoke tests. Browser console була чистою, SSR process працював, а normal request не додавав нових помилок у Laravel log.

Я не хотіла розтягувати основну integration ще одним специфічним error-page case.

Тому 404 SSR отримав окрему задачу з чітким regression scenario.

• Normal public page не створює SsrException.

• 404 page успішно SSR-renderиться.

• route('posts.index') доступний у error-page context.

• Немає ReferenceError: route is not defined.

• Немає Cannot read properties of undefined (reading 'posts.index').

• Browser console залишається чистою.

• Laravel log після контрольного 404 не містить нового Ziggy SSR exception.

• UK/EN navigation не отримує regression.

• Не довіряти старим SSR logs без контрольної мітки.

• Спочатку розділяти normal flow та error flow.

• Перевіряти backend routing configuration окремо від frontend stack trace.

• Не виправляти component тільки тому, що він останній у stack.

• Відтворюваний request цінніший за випадкову помилку в log.

Laravel Localization: логічні назви маршрутів для локалізованих URL

Laravel Ziggy: узгоджена робота в Blade, Vue та Inertia SSR

Спочатку ця помилка виглядала як нестабільний Ziggy або SSR problem, який з’являється випадково.

Насправді двох контрольних requests вистачило, щоб сильно звузити проблему: normal page була чистою, а 404 стабільно відтворював exception. Backend Ziggy configuration при цьому містила потрібний route.

Для мене головний висновок тут не тільки про Inertia SSR. Коли помилка з’являється іноді, спочатку варто довести, який саме request її створює, і тільки потім змінювати код.