Статья сохранена в админке, но в RSS её нет. Просьба «опиши архитектуру блога» даст много сведений, из которых трудно понять причину именно этого поведения. Начать лучше с одного пути: что происходит между сохранением записи и чтением ленты.
Ниже учебное исследование приложения с постами, статусом публикации и кешируемым RSS. Названия узлов условные: в вашем проекте их нужно найти, а не создавать по образцу. Здесь мы не поручаем исправление. Цель — получить карту, на которой каждое утверждение можно проверить.
У вопроса должна быть граница
Выберите наблюдаемое действие: редактор переводит запись в опубликованное состояние, после чего читатель открывает ленту. Уточните исходные данные: какая дата указана у записи, в каком окружении выполняется проверка, изменялся ли статус или только текст.
Это позволит избежать преждевременного вывода о кеше. Запись может не проходить фильтр даты, находиться в исключённой категории или просто не попадать в ограниченный набор последних материалов. Все эти причины дают похожий внешний симптом.
Исследуй путь от сохранения поста до появления в RSS. Файлы пока не меняй.
Найди:
— где сохраняются статус и дата публикации;
— какие события/наблюдатели срабатывают при сохранении;
— каким запросом RSS выбирает записи;
— где хранится кеш ленты, когда он сбрасывается и истекает;
— какие условия исключают пост из результата.
Для каждого вывода укажи файл, символ и относящийся к нему фрагмент.
Отдельно перечисли гипотезы и то, что нельзя установить по репозиторию.
Свяжите места в коде, а не просто перечислите файлы
Пять правильных путей ещё не образуют объяснение. Нужно показать, что сохранение вызывает нужный наблюдатель, наблюдатель использует тот же ключ кеша, а контроллер ленты читает данные через найденный запрос. Если один переход не подтверждён, он остаётся открытым вопросом.
Пример полезной формы ответа:
| Узел | Что установить | Чего недостаточно |
|---|---|---|
| Сохранение | Какой путь записи используется в этом действии | Найти любой метод save |
| Сброс кеша | Событие, подписчик и точный ключ | Увидеть метод с названием flush |
| Выборка RSS | Все фильтры, порядок и limit | Прочитать только имя scope |
| Вывод | Какой результат действительно передаётся шаблону | Найти похожий шаблон в другой ветке |
Вопрос о пути записи особенно полезен: обновление через модель и массовая SQL-операция могут иметь разные побочные эффекты. Как именно это устроено в конкретном фреймворке и приложении, подтверждайте реализацией и документацией его версии.
Ссылка помогает проверить вывод, но не делает его истинным
Агент может сослаться на существующую строку и неверно объяснить её роль. Например, показать фильтр опубликованных записей, но не заметить дополнительное исключение категории в запросе RSS. Поэтому проверяйте не только существование ссылки, но и переход от фрагмента к выводу.
Для долгоживущей заметки полезно сохранить имя метода и версию кода, а не один номер строки. После соседней правки номер сдвинется. При передаче результата другому человеку укажите, какой commit или рабочее состояние исследовалось; незакоммиченные изменения обозначьте отдельно.
Также не приравнивайте «не найдено» к «отсутствует». Если исследовалась только папка контроллеров, отсутствие правила там ничего не говорит о middleware, политике или обработчике события. Пусть ответ называет просмотренную область и следующую точку проверки.
Отделите код от состояния работающей системы
По репозиторию можно установить предполагаемый срок кеширования. Узнать, какой кеш сейчас лежит на сервере, обычно можно только через доступ к окружению. Конфигурационный файл не доказывает, что процесс запущен с этими значениями; старый воркер или кеш конфигурации могут использовать другое состояние.
Не просите агент незаметно переходить от чтения к очистке кеша. Такое действие меняет систему и может скрыть симптом до выяснения причины. Сначала нужен ответ: какие наблюдения подтвердят гипотезу и можно ли получить их без изменения production.
Сейчас подтверждено по коду: перечисли условия выборки и путь сброса.
Не проверено в окружении: фактические атрибуты поста, содержимое кеша,
версия запущенного процесса.
Предложи минимальное наблюдение, различающее гипотезы.
Не называй предположение установленной причиной.
Сохраните карту, которую можно обновить
Результатом может стать короткая заметка «публикация → событие → сброс → выборка RSS» с указателями на найденные места. Не переносите в общие инструкции весь диалог и все неподтверждённые версии.
В следующей задаче карта поможет выбрать место изменения. Если агент обнаружит другой путь записи, её нужно уточнить. Это полезнее обещания «изучить проект полностью»: область исследования названа, пробелы видны, а объяснение можно сопоставить с конкретным поведением.