Я увидел это на форуме сегодня
И, кажется, Discourse прав: нет dashboard.problem.sidekiq_check. Есть
на которые ссылаются здесь:
Но, похоже, Discourse ссылается на название этой проверки проблемы, вместо того чтобы использовать override_key.
3 лайка
Исправлено через:
2 лайка
Можете помочь мне понять, как работает исправление? Я вижу, что ключ перевода в server.en.yml и override_key были переименованы, чтобы соответствовать названию проверки. Интересно, почему оба нужно было переименовать, чтобы они совпадали с именем файла. Разве это не должно было работать и с sidekiq вместо sidekiq_check? Мне интересно, влияет ли на отображение предупреждения всё ещё название проверки, а не override_key, поэтому я сомневаюсь, работает ли переопределение dashboard.problem.queue_size или это текст, который никогда не отображается, как и dashboard.problem.sidekiq.
2 лайка
Да, в отдельном файле мы ссылаемся на идентификатор проверки проблем:
Таким образом, вышеупомянутый PR гарантирует, что строка в переводах совпадает с именем файла проверки проблем, которое преобразуется в этот идентификатор, т.е. sidekiq_check. Использование sidekiq в строках перевода не работало, так как оно не совпадало с идентификатором.
1 лайк
Извините, я всё ещё не совсем понимаю.
queue_size также не совпадает с именем файла/идентификатором, точно так же, как и sidekiq. И я по-прежнему не понимаю, почему в том случае это не является проблемой.
Это связано с тем, что существует другой путь выполнения кода, который напрямую использует идентификатор вместо одного из ключей переопределения? Таким образом, вместо добавления третьего ключа перевода, соответствующего имени файла, вы изменили sidekiq на использование ключа, основанного на идентификаторе? Как бы решение «два в одном», поддерживающее и случай переопределения, и случай идентификатора?
Если да, то я не понимаю, почему dashboard.problem.sidekiq_check нужно передавать в качестве ключа переопределения. Для других проверок проблем, где ключ перевода совпадает с именем файла, это не требуется. Так зачем здесь нужно переопределение?
1 лайк
Да, верно.
Оно не нужно. Скорее всего, всё работало бы нормально, если бы мы использовали return problem в строке 8 файла sidekiq_check.rb. Они эквивалентны. (Я оставил ссылку на переопределение, чтобы изменения в том PR были минимальными.)
1 лайк
Есть ли что-то, что я могу легко изменить в установочной среде разработки, чтобы вызвать сообщение об ошибке dashboard.problem.queue_size?
Я думал, что изменение
def massive_queue?
Jobs.queued >= 100_000
end
на >= 0 приведет к вызову этой ошибки, но вместо этого сработала ошибка dashboard.problem.sidekiq_check
1 лайк
Его легче воспроизвести в системных спецификациях. Я попытался это сделать, и это выявило ещё несколько проблем, это должно их исправить:
1 лайк
При переводе интерфейса Discourse иногда полезно видеть текст в контексте, поэтому я иногда пытаюсь вызывать такие предупреждения и всегда интересуюсь, как делать это проще. Возможно ли это с помощью системных тестов? Или ваше «проще» относится только к контексту проверки корректности работы кода?
Да, вы можете использовать системные тесты, чтобы просматривать переводы в контексте.
Если у вас есть среда разработки Discourse, вы можете сделать следующее:
- добавьте оператор
pause_testв системный тест, который вы хотите увидеть в браузере - запустите этот системный тест в режиме с видимым интерфейсом (headful), то есть с полноценным браузером (по умолчанию тесты запускаются в безголовом режиме, headless)
Например, для теста выше я добавил pause_test на строку 47 файла admin_notices_spec.rb, а затем запустил тест с помощью команды:
PLAYWRIGHT_HEADLESS=0 bin/rspec spec/system/admin_notices_spec.rb:47
Это запустило браузер и приостановило выполнение на указанном экране:
1 лайк