Что ж, это интересно..! Ответ JammyDodger привёл меня к новым экспериментам.
Переименование автоматических групп через настройку текста сайта вызвало путаницу, когда речь шла о пробелах, поскольку пробелы мешают использовать их в качестве обработчиков (handles). Если текущий производный обработчик не переопределяется настройкой текста сайта из-за наличия пробелов, он остаётся без изменений. Я обнаружил это, когда временно застрял заголовок группы без пробелов в качестве обработчика.
Осознание влияния пробелов и использование задания Sidekiq EnsureDbConsistency прояснило ситуацию.
Я изменю своё предложение в исходном сообщении относительно отображения правильных имён во входящих сообщениях, так как это несовместимо с использованием @-упоминаний, которые требуют обработчик.
Детальные шаги тестирования
-
Начиная с описанной выше ситуации, я подтвердил, что задание Sidekiq было выполнено, и запустил его снова. Действительно, оно не уловило изменения имён для входящих сообщений — из-за пробелов, как вы и объяснили.
-
Изменил текст сайта для TL2 с “Trust Level 2” на “Sophomores” и запустил задание Sidekiq:
Теперь изменение имени распространилось как на заголовок группы, так и на обработчик во входящих сообщениях — потому что пробелов нет:
- Вернул имя текста сайта обратно на “Trust Level 2” и запустил задание Sidekiq. Обработчик, назначенный в предыдущей операции, теперь застрял там — очевидно, потому что пробелы в этом заголовке текста сайта делают его недопустимым обработчиком:
- Вернул текст сайта к значению по умолчанию “trust_level_2” и не запускал задание Sidekiq. Это обновило заголовок, но не обработчик:
- Запустил задание Sidekiq, которое очистило изменённый обработчик, сбросив его на значение по умолчанию во входящих сообщениях:
