HTTP 200 у файла выгрузки подтверждает успешный ответ на запрос, но не свежесть цен, остатков или отчёта. Проверять нужно возраст исходных данных и последнюю успешно опубликованную выгрузку, а затем — копию, которую действительно получил потребитель.
Начните с одного URL и одного ожидаемого изменения. Сопоставьте четыре точки: источник → генератор → доступный файл → импорт. Так станет понятно, где остановилось обновление, без перезапуска всех заданий и очистки всего CDN.
1. Определите, что считать свежими данными
Для владельца магазина важен срок актуальности остатков, для аналитика — дата закрытого периода отчёта. Вместе с ответственным за данные задайте расписание, допустимую задержку и часовой пояс; универсального порога для любой выгрузки нет.
Разделите два времени: когда файл собран и до какого момента в нём учтены изменения источника. Новый файл, созданный из вчерашнего снимка базы, остаётся устаревшим для задачи, требующей текущих данных.
Полезно предусмотреть в формате или отдельном служебном описании:
generated_at— время успешного формирования;source_updated_at— подтверждённую границу актуальности источника;export_id— идентификатор опубликованной сборки;- количество записей и результат проверки полноты.
Это предлагаемые поля, а не обязательный стандарт. Если источник не позволяет определить границу актуальности, так и фиксируйте: время сборки известно, свежесть исходных данных не подтверждена.
2. Получите именно тот файл, который читает интеграция
Проверьте точный адрес, параметры и конечный URL после редиректов. Для публичного файла без секретов можно выполнить GET в локальной рабочей папке:
curl -sS -L --max-redirs 5 --max-time 60 --compressed \
-D export-headers.txt -o export-body.bin \
-w 'code=%{http_code} final=%{url_effective}\n' \
'https://example.com/export/catalog.xml'Команда скачивает тело и сохраняет заголовки; значение code относится к последнему HTTP-ответу. Если curl завершился с ошибкой, не анализируйте неполный файл как успешную выгрузку. Размер и время ожидания подбирайте под свой файл, без частых повторных скачиваний большой выгрузки.
Откройте сохранённое тело: это должен быть ожидаемый XML, CSV или JSON, а не страница входа либо текст ошибки с кодом 200. Проверьте синтаксис подходящим парсером и одну запись, изменение которой точно подтверждено в источнике.
По руководству curl, -D сохраняет заголовки, -o — тело ответа. Не переносите в команды для общего тикета Cookie, Authorization, подписанные ссылки или содержимое закрытых выгрузок.
3. Отделите свежесть файла от HTTP-метаданных
Date относится ко времени HTTP-сообщения, а Last-Modified — к последнему изменению представления по оценке сервера. Они не удостоверяют, что каталог сформирован из актуальной базы. Значение ETag также нельзя интерпретировать как дату или номер выгрузки без отдельного контракта — это непрозрачный валидатор. Эти значения определены в RFC 9110.
Age помогает оценивать возраст закэшированного ответа, но не возраст записей в базе; отсутствие этого заголовка тоже не доказывает свежесть данных. Правила HTTP-кэша описаны в RFC 9111. Если генератор уже выдал новую сборку, а публичный URL отдаёт старую, продолжите по инструкции проверки HTTP-кэша.
Не начинайте с массовой очистки кэша: сначала сохраните идентификатор сборки и безопасные диагностические заголовки проблемного ответа.
4. Найдите участок, на котором обновление остановилось
В источнике нет ожидаемого изменения
Проверьте завершение исходного обмена, выбранную базу или реплику и фильтры выгрузки. Свежий запуск генератора не исправит отставший источник. Не используйте максимальную дату среди строк как единственное доказательство: она не подтверждает полноту набора и учёт удалений.
Источник актуален, но новой сборки нет
Сопоставьте расписание с фактическим запуском и завершением задания, блокировкой от параллельного запуска, журналом ошибок и правами записи. Отметка «процесс стартовал» не равна успешной публикации. До ручного повтора выясните, не работает ли предыдущая задача и безопасен ли повторный запуск.
Новая сборка есть, а по URL доступна старая
Сравните идентификаторы файла у генератора, в хранилище и в скачанном ответе. Проверьте путь публикации, имя объекта, узел сервера и кэш. Если есть контрольная сумма, сравнивайте одинаково представленные полные файлы: различное сжатие меняет байты.
Для будущих запусков полезна схема: собрать отдельный файл, проверить его, затем переключить публикацию способом, который хранилище поддерживает атомарно. Читатель не должен получать половину новой выгрузки под прежним адресом.
По URL данные новые, а в системе-получателе старые
Проверьте время последней загрузки потребителем, полученный export_id, ошибки разбора, фильтры и результат импорта. Факт скачивания не доказывает применение данных. Если изменились поля или типы, пригодится отдельный разбор контракта API.
5. Закрепите проверку возраста и полноты
Контроль свежести должен сравнивать текущее время с подтверждённой границей актуальности, учитывать расписание и допустимую задержку. Некорректная, отсутствующая или неожиданно будущая дата — отдельная ошибка контроля, а не зелёный результат.
Проверяйте также полноту: свежий пустой файл может быть корректным по расписанию и бесполезным для импорта. Условия допустимого пустого результата и ожидаемые изменения количества записей согласуйте с владельцем данных.
Web-Puls можно использовать для регулярного контроля доступности публичного URL. Расчёт возраста данных и подтверждение импорта требуют отдельной проверки в вашей интеграции: обычный HTTP-мониторинг их не заменяет.
Если место остановки обновления осталось неясным, отправьте заявку на диагностику с публичным URL, расписанием, временем последней удачной выгрузки и обезличенными результатами сравнения четырёх точек. Формат и стоимость работ согласуют до начала; закрытый файл и доступы в описание заявки не включайте.