Ich habe das heute in einem Forum gesehen
Und ich denke, Discourse hat recht: Es gibt kein dashboard.problem.sidekiq_check. Es gibt
die hier referenziert werden:
Aber es scheint, dass Discourse sich stattdessen auf den Namen dieser Problemprüfung bezieht.
Behoben durch:
Könntest du mir helfen zu verstehen, wie die Korrektur funktioniert? Ich sehe, dass der Überschlüssel in server.en.yml und override_key umbenannt wurden, um dem Namen des Checks zu entsprechen. Ich frage mich, warum beide umbenannt werden mussten, um dem Dateinamen zu entsprechen. Hätte es nicht auch mit sidekiq statt sidekiq_check funktioniert? Ich frage mich, ob es immer noch der Name des Checks und nicht der override_key ist, der beeinflusst, welche Warnung angezeigt wird. Daher frage ich mich, ob die Überschreibung dashboard.problem.queue_size funktioniert oder ob das ein Text ist, der niemals angezeigt wird, genau wie dashboard.problem.sidekiq nicht angezeigt wurde.
Ja, wir verweisen in einer separaten Datei auf die Problem-Check-Identifikator:
Der oben genannte PR stellt sicher, dass der String in den Übersetzungen mit dem Dateinamen des Problem-Checks übereinstimmt, der in diesen Identifikator umgewandelt wird, also sidekiq_check. Die Verwendung von sidekiq in den Übersetzungsstrings hat nicht funktioniert, da sie nicht mit dem Identifikator übereinstimmte.
Entschuldigung, ich verstehe es immer noch nicht wirklich.
queue_size stimmt ebenfalls nicht mit dem Dateinamen/der Kennung überein, genau wie es bei sidekiq der Fall war. Und ich verstehe immer noch nicht, warum das in diesem Fall kein Problem ist.
Liegt das daran, dass es einen weiteren Codepfad gibt, der die Kennung direkt verwendet, anstatt einen der Überschreibungsschlüssel? Also hast du statt eines dritten Übersetzungsschlüssels, der dem Dateinamen entspricht, sidekiq so geändert, dass er den kennungsbasierten Schlüssel verwendet? Eine Art Zwei-in-Eins-Lösung, die sowohl den Überschreibungsfall als auch den Kennungsfall unterstützt?
Wenn dem so ist, verstehe ich nicht, warum dashboard.problem.sidekiq_check als Überschreibungsschlüssel übergeben werden muss. Die anderen Problemprüfungen, bei denen der Übersetzungsschlüssel mit dem Dateinamen übereinstimmt, benötigen das nicht. Warum ist hier also eine Überschreibung nötig?
Ja, genau.
Er ist nicht nötig. Es würde wahrscheinlich genauso gut funktionieren, wenn wir in Zeile 8 von sidekiq_check.rb return problem schreiben. Beide Varianten sind äquivalent. (Ich habe den Verweis auf den Override beibehalten, um den Änderungsumfang in jenem PR damals kleiner zu halten.)
Gibt es etwas, das ich in einer Entwicklungsumgebung einfach ändern kann, um die Fehlermeldung dashboard.problem.queue_size auszulösen?
Ich dachte, wenn ich
def massive_queue?
Jobs.queued >= 100_000
end
in >= 0 ändere, würde dieser Fehler ausgelöst werden – stattdessen wurde jedoch dashboard.problem.sidekiq_check ausgegeben.
Es ist einfacher, dies in Systemspezifikationen zu reproduzieren. Ich habe das versucht, und dabei sind weitere Probleme zutage getreten. Dies sollte sie beheben:
Bei der Übersetzung der Discourse-Oberfläche ist es manchmal hilfreich, den Text im Kontext zu sehen. Aus diesem Grund versuche ich manchmal, solche Warnungen auszulösen, und bin stets daran interessiert, zu lernen, wie man dies einfacher bewerkstelligen kann. Ist das mit Systemtests möglich? Oder bezieht sich dein „einfacher“ nur auf den Kontext der Sicherstellung, dass der Code wie erwartet funktioniert?
Ja, Sie können System-Specs verwenden, um Übersetzungen im Kontext zu sehen.
Wenn Sie eine Entwicklungsumgebung für Discourse haben, können Sie folgendes tun:
pause_test-Anweisung in die System-Spec ein, die Sie im Browser sehen möchten.Zum Beispiel habe ich für die oben genannte Spec pause_test in Zeile 47 von admin_notices_spec.rb hinzugefügt und die Spec dann mit folgendem Befehl ausgeführt:
PLAYWRIGHT_HEADLESS=0 bin/rspec spec/system/admin_notices_spec.rb:47
Dadurch wurde ein Browser gestartet und an diesem bestimmten Bildschirm pausiert:
