Да, когда пользователь удаляется, мы убираем его из всех мероприятий, на которые он подтвердил участие. Возможно, именно этот код вызывает проблему.
3 лайка
Потому что все ID тем в ошибке относятся к темам, использующим модуль «События».
Хм, я вполне уверен, что эти конкретные пользователи, которых я удаляю, не подтверждали участие, хотя, возможно, это единственные темы, в которых включена функция подтверждения участия?
3 лайка
О-о, понял.
@fzngagan здесь используется небезопасный .find(?
topics = Topic.find(topic_ids) if topic_ids
Смотрите выше исправление, которое я только что отправил в Follow (хотя решение здесь может потребовать иных подходов, так как IDs несколько — возможно, стоит использовать where?).
3 лайка
Я только что обновился, но всё ещё получаю ошибку 404.
1 лайк
Барт, подожди, пока @fzngagan применит и подтвердит исправление.
5 лайков
Я применил исправление. Надеюсь, это решит проблему. Пожалуйста, проверьте и подтвердите.
5 лайков
Это исправило проблему, спасибо!!
6 лайков
Я уже несколько раз видел в очереди на проверку посты с пометкой «Новый пользователь опубликовал первое сообщение подозрительно быстро». При более тщательной проверке я заметил, что в этих постах присутствовали отслеживаемые слова, однако в очереди на проверку это не указывалось.
Поскольку пометка «Новый пользователь опубликовал первое сообщение подозрительно быстро» в 96 % случаев ошибочна, а пометка «Отслеживаемые слова» в 100 % случаев верна (то есть если пост попадает в очередь на проверку из-за отслеживаемого слова, то в 100 % случаев это действительно пост, требующий внимания), я считаю, что пометка «Отслеживаемые слова» должна иметь приоритет над «Новый пользователь опубликовал слишком быстро».
Представьте следующие ситуации:
- Пост попадает в очередь на проверку из-за пометки «Новый пользователь опубликовал первое сообщение подозрительно быстро». В этом посте содержится невидимая спам-ссылка, которая есть в списке отслеживаемых слов. → Пост одобряется, поскольку никто не замечает невидимую ссылку (например, ссылка скрыта за точкой). → Провал!
- Пост попадает в очередь на проверку из-за отслеживаемого слова (приоритет «Отслеживаемые слова» над «Опубликовано слишком быстро»). В этом посте содержится невидимая спам-ссылка, которая есть в списке отслеживаемых слов. → Пост отклоняется, а спамер удаляется из-за наличия отслеживаемых слов → Победа!
5 лайков
Абсолютно верно, это пограничный баг. Не могли бы мы добавить это в чей-то список, @eviltrout? Вижу, что @Roman всё ещё назначен, возможно, ему?
4 лайка
Исправлено здесь:
8 лайков
Версия 2.6.0.beta2. Просто предупреждение: у меня в очереди на модерацию появились темы, которые, похоже, были удалены. Полагаю, это происходит примерно так:
- Сообщение пользователя попадает в очередь на проверку из-за слишком быстрого набора текста.
- Пользователь удаляет свою тему (если это возможно), возможно, чтобы отправить её заново.
Не уверен, является ли это ожидаемым поведением. В очереди на модерацию заголовок пуст, но тело сообщения присутствует, а пользователь замолчан. В публичном профиле пользователя не видно никаких тем или сообщений.
Не относится к вышеизложенному. У меня есть предложение по улучшению параметров фильтрации. Функция, которая, на мой взгляд, была бы очень полезна, — это более детальный фильтр по типам сообщений/тем. Сейчас в разделе «Типы» у нас есть:
Помеченные сообщения и сообщения в очереди включают как темы, так и отдельные посты. Я считаю, что было бы гораздо полезнее изменить это на следующее:
Тип проверки:
- Помеченные
- В очереди
Также можно рассмотреть возможность разделения «Помеченных» на «Помеченные пользователем» и «Помеченные системой».
Затем добавить отдельный фильтр для типа контента:
Тип контента:
- Тема
- Сообщение
- Пользователь
Считаю, что это было бы очень полезно. Например, это позволило бы быстро расставлять приоритеты: сначала утверждать темы, а затем отдельные сообщения/ответы. В текущих фильтрах, кроме группировки по темам, нет способа отличить темы от сообщений.
Ещё одно предложение — доработать интерфейс очереди на модерацию, чтобы темы и сообщения было легче различать. Сейчас эта информация отображается мелким серым текстом (например, «Сообщение в очереди», «Тема в очереди», «Помеченное сообщение», «Помеченная тема»). Размер шрифта такой же, как у категорий и тегов темы/сообщения.
Для меня не сразу очевидно, является ли элемент темой или сообщением/ответом, и я часто их путаю.
Несколько идей:
- Изменить раздел «Заголовок темы» в элементах сообщений: добавить иконку ответа, сделать его меньше, чем для тем, и, возможно, добавить текст «RE:».
- Увеличить размер шрифта и выделить тип элемента (Тема/Сообщение).
2 лайка
При попытке одобрить темы и сообщения я получаю ошибку 500. В данный момент используется версия 2.6.0.beta3. Вот лог:
ActiveRecord::RangeError (PG::NumericValueOutOfRange: ERROR: integer out of range
)
app/models/reviewable_queued_post.rb:97:in `perform_approve_post'
app/models/reviewable.rb:355:in `public_send'
app/models/reviewable.rb:355:in `block in perform'
app/models/reviewable.rb:353:in `perform'
app/controllers/reviewables_controller.rb:192:in `perform'
app/controllers/application_controller.rb:347:in `block in with_resolved_locale'
app/controllers/application_controller.rb:347:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'
Возможно, имеет значение, что ранее у меня был установлен Akismet, который я удалил (также выполнив соответствующую задачу Rake), как подробно описано здесь: Feedback on the new Review Queue (2019) - #210 by markersocial
Сообщения относятся к последним 60 дням (auto_handle_queued_age: 60). Я пробовал как со старыми сообщениями (~2 месяца), так и с недавними (в течение последних 3 часов).
Я могу одобрять пользователей (Тип: User), и опция «Удалить пользователя» для тем/сообщений в очереди работает.
2 лайка
@Roman это что-то странное — откуда у нас здесь такое большое число?
6 лайков
Ошибка возникает при попытке создать уведомление:
Подозреваю, что мы, вероятно, храним
Возможно, мы храним некоторые идентификаторы, используя тип int? Начиная с версии 5.1, Rails начал использовать BIGINT(8) для первичных ключей.
@markersorcial, не могли бы вы поделиться с нами результатами выполнения этих запросов?
Notification.count
User.count
Topic.count
4 лайка
Спасибо, что уделили время 
Конечно, вот результаты запроса:
Notification.count: 1506604
User.count: 238083
Topic.count: 936067
3 лайка
Обновление: Просматривая Sidekiq, я вижу много неудачных задач с похожей ошибкой:
Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERROR: integer out of range
Для следующих типов задач (которые я пока заметил):
Jobs::PostAlert (наиболее часто)
Jobs::ProcessPost
Jobs::NotifyCategoryChange
1 лайк
Ни одно из этих чисел не должно превышать максимальный размер. Интересно, не перезаписывает ли что-то другое значение целого числа, @Roman.
3 лайка
Тогда это должно быть что-то другое. Что-то определённо происходит, и это не связано конкретно с очередью рецензий.
Эти задания создают уведомления, и они тоже завершаются неудачей:
Кроме того, если я попробую сделать что-то вроде этого:
Notification.create!(
notification_type: Notification.types[:post_approved],
user_id: 1,
data: {},
topic_id: 1,
post_number: 1311344111111
)
Я получаю другую ошибку:
ActiveModel::RangeError: 1311344111111 выходит за пределы диапазона для ActiveModel::Type::Integer с ограничением 4 байта
Та же ошибка возникает при выполнении этого:
DB.exec <<~SQL
INSERT INTO notifications(user_id, topic_id, post_number)
VALUES (1, 1, 1311344111111)
SQL
PG::NumericValueOutOfRange: ERROR: integer out of range
6 лайков
@markersocial Интересно, помогут ли логи PostgreSQL получить больше информации об ошибке. Не могли бы вы проверить?
Если вы не знаете, где найти логи, см.:
5 лайков
Наши модераторы ценят возможность легко обсуждать помеченные сообщения между собой, при этом история сохраняется в очереди проверки. Возможно ли добавить аналогичную возможность для сообщений в очереди? Мы используем настройку approve_post_count, чтобы требовать одобрения для первых 5 сообщений новых пользователей. Эти первые 5 сообщений становятся сообщениями в очереди, но если требуется обсуждение модераторами, им приходится создавать личное сообщение, которое не связано с очередью проверки, и история теряется.
3 лайка