Возможная проблема регрессии события post_edited?

Отчёт об ошибке Discourse: регрессия события :post_edited в ветке latest-release

Затрагивает: ветку Discourse latest-release (release +122)
Статус: подтверждённая регрессия — воспроизводится
Дата: 15 января 2026 г.


Краткое описание

Событие :post_edited (DiscourseEvent) перестало публиковаться в последних сборках ветки latest-release. Редактирование постов проходит успешно, ревизии создаются, но событие, от которого зависят плагины, никогда не срабатывает. Это ломает все плагины, использующие триггер автоматизации post_created_edited, а также любые другие плагины, слушающие события :post_edited.


Воспроизведение (подтверждено)

Мы подтвердили, что это регрессия, протестировав две идентичные среды Azure AKS:

До обновления (работает)

  • Версия: v2026.1.0-latest (старая сборка)
  • Поведение: :white_check_mark: События :post_edited срабатывают корректно
  • Автоматизация: :white_check_mark: Работает автоматически

После обновления (сломано)

  • Версия: latest-release +1221 час назад, release +122
  • Поведение: :cross_mark: События :post_edited никогда не срабатывают
  • Автоматизация: :cross_mark: Полностью неработоспособна

Критическое обнаружение: обе среды работали до обновления. Обе сломались после обновления до latest-release +122. Это окончательно доказывает, что была внесена регрессия.


Детали окружения

  • Версия Discourse: latest-release (release +122)
  • Версия Rails: 8.0.4
  • Инфраструктура: Azure Kubernetes Service (AKS)
  • Docker-образ: discourse/base:2.0.20260109-0020
  • Развёртывание: стандартная установка Discourse через Docker

Процедура тестирования

Тест 1: Слушатель событий (доказывает, что событие никогда не срабатывает)

# В консоли Rails
File.open('/tmp/post_edited_test.log', 'w') { |f| f.write("Тест начат в #{Time.now}\n") }

DiscourseEvent.on(:post_edited) do |post, topic_changed, revisor|
  File.open('/tmp/post_edited_test.log', 'a') do |f|
    f.write("[#{Time.now}] :post_edited сработал! Пост #{post.id}\n")
  end
end

Затем отредактируйте любой пост через веб-интерфейс и проверьте:

cat /tmp/post_edited_test.log

Результат на latest-release +122: показывается только «Тест начат» — событие никогда не срабатывает
Результат на старой сборке: показываются записи событий с временными метками и ID постов

Тест 2: Проверка создания ревизий

post = Post.find(ID_ПОСТА)
puts "Ревизии поста: #{post.revisions.count}"
post.revisions.last(3).each { |rev| puts "  Ревизия #{rev.number}: #{rev.created_at}" }

Результат: Ревизии создаются корректно с правильными временными метками
Вывод: Редактирование обрабатывается успешно, но метод post_process_post не вызывается или событие не инициируется

Тест 3: Ручное триггерирование события (доказывает, что система событий работает)

post = Post.find(ID_ПОСТА)
DiscourseEvent.trigger(:post_edited, post, false, PostRevisor.new(post))

Результат: Обработчики событий выполняются корректно
Вывод: Система событий работает, но автоматическое триггерирование при редактировании сломано


Ожидаемое поведение

При редактировании поста через веб-интерфейс:

  1. Редактирование успешно сохраняется :white_check_mark:
  2. Создаётся ревизия поста :white_check_mark:
  3. Вызывается PostRevisor#post_process_post :cross_mark:
  4. Срабатывает событие :post_edited :cross_mark:
  5. Выполняются обработчики событий :cross_mark:

Работают только шаги 1–2. Шаги 3–5 сломаны.


Фактическое поведение

Продакшн-логи показывают успешное завершение редактирования:

Started PUT "/posts/3631" for 88.97.179.124 at 2026-01-15 13:06:19 +0000
Processing by PostsController#update as JSON
Completed 200 OK in 676ms

Нет ошибок, нет исключений, но событие :post_edited не публикуется.

Событие должно срабатывать в файле /var/www/discourse/lib/post_revisor.rb, строка 759:

def post_process_post
  @post.invalidate_oneboxes = true
  @post.trigger_post_process
  DiscourseEvent.trigger(:post_edited, @post, self.topic_changed?, self)
end

Этот метод вызывается из строки 341, но событие не срабатывает.


Влияние

Затронутые официальные функции

  • Discourse Automation: триггер post_created_edited полностью неработоспособен
  • Любые рабочие процессы автоматизации, зависящие от редактирования постов, терпят неудачу молча

Затронутые плагины

Все плагины, слушающие события :post_edited, сломаны:

  • discourse-automation — официальные триггеры автоматизации
  • discourse-ai — AI-модерация отредактированных постов
  • discourse-doc-categories — обновления индекса документации
  • discourse-topic-voting — рабочие процессы возврата голосов
  • Любые пользовательские плагины, использующие события редактирования постов

Хронология регрессии

  1. Старая сборка: v2026.1.0-latest — события :post_edited работали :white_check_mark:
  2. Обновление до: latest-release (release +122) — события :post_edited сломаны :cross_mark:
  3. Подтверждено на: двух отдельных продакшн-окружениях (оба сломались после обновления)

Это окончательно доказывает, что регрессия была внесена в последних сборках latest-release.


Обходной путь

Ручное триггерирование через консоль Rails работает:

automation = DiscourseAutomation::Automation.find(ID_АВТОМАТИЗАЦИИ)
post = Post.find(ID_ПОСТА)
automation.trigger!({"post" => post})

Это подтверждает, что сама система автоматизации работает — сломано только автоматическое триггерирование событий.


Заметки по конфигурации

  • Проверенные настройки: все настройки, связанные с редактированием, стандартные/по умолчанию
  • Период прощения: тестировалось с редактированием далеко за пределами периода прощения (без эффекта)
  • Плагины: установлено 50 плагинов (стандартные официальные плагины)
  • Нет изменений ядра: чистая установка Discourse
  • Окружение: обе тестовые среды — идентичные развёртывания Azure AKS

Ключевые доказательства

Самое важное обнаружение:

У нас была рабочая DEV-среда на старой сборке. После обновления до latest-release +122 автоматизация перестала работать. Это с абсолютной уверенностью доказывает, что регрессия была внесена в последних релизах.

Обе среды теперь демонстрируют идентичное сломанное поведение после перехода на одну и ту же версию.


Воспроизводимость

100% воспроизводимо — протестировано на двух независимых окружениях:

  1. Установить Discourse latest-release (release +122)
  2. Создать автоматизацию с триггером post_created_edited
  3. Отредактировать пост
  4. Наблюдать, что автоматизация никогда не срабатывает
  5. Подтвердить, что событие :post_edited никогда не срабатывает, используя тестового слушателя

Краткое описание

Это подтверждённая регрессия в latest-release (release +122). Событие :post_edited работало в предыдущих версиях и перестало работать после обновления. Два независимых окружения подтвердили одинаковое поведение. Это ломает основную функциональность Discourse Automation и все плагины, зависящие от событий редактирования постов.

Это не так работает DiscourseEvent — он не межпроцессный, а внутрипроцессный. Поэтому события перехватываются только слушателями в том же процессе, что и процесс, который их инициировал.

В случае с автоматизацией Discourse я только что протестировал это локально со следующими настройками

отредактировал пост, и сообщение в чат было успешно отправлено

Спасибо! Я вернусь к этому, так как явно неправильно понял. Надеюсь, с этой информацией мне удастся заставить мой плагин работать. Большое спасибо,

Спасибо @zogstrip — мы также протестировали ситуацию, наблюдая за логами продакшена во время редактирования через веб-интерфейс:

Процедура тестирования:

  1. Сбросили задержку автоматизации через консоль
  2. Просматривали логи: tail -f /var/www/discourse/log/production.log | grep "PDF Automation"
  3. Отредактировали пост через веб-браузер (тот же процесс, что и при автоматизации)
  4. Результат: Редактирование завершается успешно (200 OK), но автоматизация никогда не запускается

У нас две идентичные среды (DEV и PROD на Azure AKS):

  • До обновления: автоматизация в DEV работала идеально (появлялись записи в файле логов)
  • После обновления до latest-release (+122): автоматизация перестала работать как в DEV, так и в PROD
  • Тест через веб-интерфейс: запусков автоматизации по-прежнему нет

Наша конфигурация автоматизации:

  • Триггер: post_created_edited
  • Скрипт: пользовательский скрипт (run_pdf_generation)
  • Фильтр: ID категории 34, тег “hd96-24”

Может ли быть что-то специфичное в пользовательских скриптах или нашей среде, что препятствует запуску автоматизации? Тот факт, что это работало до обновления, говорит о том, что что-то изменилось в том, как срабатывают триггеры post_created_edited.

Не могли бы вы попробовать более «простую» автоматизацию с тем же триггером? Есть ли что-то потенциально связанное в /logs?

Хорошая идея — я создам минимальный пример для воспроизведения проблемы и отправлю его в понедельник. Хороших выходных :slight_smile:

Вы были абсолютно правы насчет проблемы межпроцессного взаимодействия с DiscourseEvent — спасибо за это уточнение!

После ваших замечаний мы провели корректное тестирование с помощью простой автоматизации send_chat_message, используя тот же триггер post_created_edited. При редактировании поста автоматизация сработала (мы увидели её выполнение в логах и получили ошибку 500 из-за некорректной настройки параметров чата, а не самого триггера).

Это подтверждает: триггер post_created_edited работает корректно.

Наше недопонимание возникло из-за:

  1. Тестирования с помощью слушателя в консоли Rails (неверно — межпроцессное взаимодействие)
  2. Нашего пользовательского скрипта для PDF, который был утерян при пересборке, и у нас возникли трудности с его повторной постоянной регистрацией

Сам механизм триггера работает как ожидалось. Извините за путаницу и спасибо за помощь!

Рад, что всё работает как ожидалось :+1:

Теперь сложная часть — выяснить, почему ваш пользовательский скрипт run_pdf_generation больше не работает :sweat_smile: