Astro 7.3: что проверить в собственном Cloudflare Worker

В Astro 7.3 появился повод проверить собственный Cloudflare Worker: ответ из Astro-пайплайна должен пройти завершение, которое применяет cookies и стандартные CDN cache-заголовки адаптера. Для собственного Fetch-обработчика предусмотрен finalize. При этом готовый обработчик адаптера и вариант с Hono нельзя механически дополнить тем же вызовом: сначала определите, кто уже завершает ответ.

Новость относится к конкретной границе ответа

Astro 7.3 выпущен 3 сентября 2026 года. Вместе с ним анонсирован helper finalize для собственных worker entrypoints в @astrojs/cloudflare. В том же выпуске runtime logger передаётся собственным сервисам изображений и cache providers. Это две отдельные возможности: корректный ответ и наблюдаемость расширений.

Документация Cloudflare-адаптера описывает передачу в finalize того же FetchState и ответа Astro перед возвратом. Для Hono middleware само применяет завершение. Стандартный entrypoint адаптера также выполняет необходимую настройку; собственные companion handlers заменяют его работу, а не добавляются одновременно с ним.

Сначала найдите все места, где Worker возвращает ответ

Своя точка входа может обслуживать несколько путей. Одни запросы доходят до рендеринга Astro, другие возвращают ресурс раньше. Ещё могут быть ответы, сформированные вашей логикой. Если проверять только один return в конце файла, легко не заметить реально используемый путь.

Мы советуем выписать происхождение каждого ответа и ожидаемые свойства. Не нужно применять механизм адаптера к любой Response по совпадению типа. Вопрос точнее: относится ли ответ к описанному Astro-пайплайну, какое состояние сопровождало запрос и где выполняется его завершение.

Карта приёмки собственного entrypoint

Матрица — наш учебный план проверки, не описание обнаруженной утечки. Для проекта выбирайте только существующие сценарии. Политика кеширования должна исходить из назначения данных; helper не заменяет решение, можно ли повторно использовать конкретный ответ.

Проверить cookie нужно после всей цепочки

В учебной ситуации страница сообщает, что настройка сохранена, а следующий запрос снова видит прежнее значение. Проверка только функции рендеринга не объясняет результат: надо увидеть итоговые заголовки и последующий разрешённый запрос того же пользователя. Не записывайте содержимое настоящих сессионных cookies в общий журнал.

Отдельно пройдите переход между общей и личной страницей на тестовых данных. Требуется подтвердить ожидаемое разделение ответов, а не получить любой признак кеша. Наличие CDN не является доказательством корректной политики приложения.

Логирование помогает найти путь, но не исправляет его

Новый logger для расширений полезен, когда предупреждение собственного сервиса изображений или cache provider должно следовать общей настройке журналирования. Но одно появившееся сообщение не подтверждает корректность завершения ответа. В журнале должны различаться происхождение события и проверяемая операция.

1. Установите, используется ли стандартный entrypoint, собственный Fetch или Hono.
2. Для собственного Worker перечислите ветки возврата ответа.
3. Сопоставьте Astro-ветку с документированным завершением и общим FetchState.
4. Проверьте cookie и правила кеша на итоговой границе ответа.
5. Повторите характерную операцию с тестовыми данными.
6. Сохраните наблюдения и нерешённые ветки отдельно от успешных.

Не требуется запускать множество preview-серверов ради такой приёмки. Достаточно управляемой проверки выбранной поставки и понятного соответствия запросов результатам. Сам номер Astro также не подтверждает версию установленного адаптера: её фиксируют отдельно.

Для разработки веб-приложения запишите владельца итогового ответа. При сопровождении серверной части сохраняйте карту маршрутов, а в проверке защиты данных согласуйте правила личных страниц. Эта конкретика позволяет проверить изменение, не обещая автоматической безопасности после обновления пакета.