Vi esto hoy en un foro
Y creo que Discourse tiene razón: no existe dashboard.problem.sidekiq_check. Existen
que se referencian aquí:
Pero parece que Discourse se refiere al nombre de esa comprobación de problemas en su lugar.
3 Me gusta
Corregido mediante:
2 Me gusta
¿Puedes ayudarme a entender cómo funciona la corrección? Veo que la clave de traducción en server.en.yml y override_key han sido renombradas para coincidir con el nombre de la comprobación. Me pregunto por qué ambas necesitaban ser renombradas para coincidir con el nombre del archivo. ¿No debería haber funcionado también con sidekiq en lugar de sidekiq_check? Me pregunto si sigue siendo el nombre de la comprobación, en lugar de override_key, lo que influye en qué advertencia se muestra, así que me pregunto si la sobrescritura dashboard.problem.queue_size funciona o si ese es un texto que nunca se muestra, al igual que dashboard.problem.sidekiq no se mostraba.
2 Me gusta
Sí, hacemos referencia en un archivo separado al identificador de comprobación de problemas:
Por lo tanto, la PR anterior se asegura de que la cadena en las traducciones coincida con el nombre del archivo de comprobación de problemas, que se convierte en ese identificador, es decir, sidekiq_check. Usar sidekiq en las cadenas de traducción no funcionaba, ya que no coincidía con el identificador.
1 me gusta
Lo siento, sigo sin entenderlo del todo.
queue_size tampoco coincide con el nombre del archivo/identificador, al igual que sidekiq no lo hacía. Y sigo sin entender por qué esto no es un problema en ese caso.
¿Se debe a que hay otra ruta de código que utiliza directamente el identificador en lugar de una de las claves de anulación? Entonces, en lugar de agregar una tercera clave de traducción que coincida con el nombre del archivo, cambiaste sidekiq para que use la clave basada en el identificador. ¿Una especie de solución dos en uno que soporta tanto el caso de anulación como el caso de identificador?
Si es así, no entiendo por qué dashboard.problem.sidekiq_check necesita pasarse como clave de anulación. Las otras verificaciones de problemas donde la clave de traducción coincide con el nombre del archivo no necesitan eso. Entonces, ¿por qué se necesita una anulación aquí?
1 me gusta
Sí, correcto.
No es necesaria. Probablemente funcionaría bien si hiciéramos return problem en la línea 8 de sidekiq_check.rb. Son equivalentes. (Mantuve la referencia a la anulación para que el cambio en ese PR fuera menor en ese momento.)
1 me gusta
¿Hay algo que pueda cambiar fácilmente en una instalación de desarrollo para activar el mensaje de error dashboard.problem.queue_size?
Pensé que cambiar
def massive_queue?
Jobs.queued >= 100_000
end
a >= 0 provocaría que se activara ese error, pero esto dio como resultado dashboard.problem.sidekiq_check
1 me gusta
Es es más fácil de reproducir en las especificaciones del sistema. Intenté hacerlo y eso reveló algunos problemas más, esto debería solucionarlos:
1 me gusta
Para traducir la interfaz de Discourse, a veces resulta útil ver el texto en su contexto, por lo que en ocasiones intento provocar dichas advertencias y siempre me interesa aprender a hacerlo de manera más sencilla. ¿Es posible hacerlo con las pruebas del sistema? O ¿se refiere tu “más fácil” únicamente al contexto de garantizar que el código funcione como se espera?
Sí, puedes usar las especificaciones del sistema para ver las traducciones en contexto.
Si tienes un entorno de desarrollo para Discourse, puedes hacer algo como esto:
- añade una declaración
pause_testen la especificación del sistema que quieras ver en un navegador - ejecuta esa especificación del sistema en modo headful, es decir, con un navegador completo (por defecto, las especificaciones se ejecutan en modo headless)
Por ejemplo, para la especificación anterior, añadí pause_test en la línea 47 de admin_notices_spec.rb y luego ejecuté la especificación con:
PLAYWRIGHT_HEADLESS=0 bin/rspec spec/system/admin_notices_spec.rb:47
Esto lanzó un navegador y se pausó en esa pantalla específica:
1 me gusta