Los usuarios admin siempre obtienen un error 500 de tiempo de espera en GitUtils.has_commit?, mientras que los usuarios normales funcionan correctamente

Hola a todos,

Tengo un problema extraño con una instalación nueva de Discourse y agradecería cualquier orientación.

Entorno

  • Discourse Docker (estable más reciente)
  • Ubuntu 24.04
  • Instalación nueva usando discourse_docker
  • Sin plugins excepto OpenID Connect
  • Repositorio Git limpio
  • Proxy inverso con nginx
  • Solo HTTP (sin HTTPS aún)
  • Repositorio Git local existe y está en la rama latest

El comportamiento extraño

Usuarios anónimos:

  • :white_check_mark: La página principal carga normalmente

Usuarios normales autenticados:

  • :white_check_mark: Funcionan normalmente

Usuarios autenticados a través de OpenID Connect:

  • :white_check_mark: Funcionan normalmente

Pero cada usuario administrador local de Discourse obtiene un tiempo de espera y finalmente:


Ups

El software que impulsa este foro de discusión encontró un problema inesperado.

o a veces


El servidor está experimentando alta carga actualmente.

Lo que probamos

Creamos un nuevo administrador local usando


rake admin:create

Resultado:

  • usuario como Administrador → :cross_mark: tiempo de espera 500
  • mismo usuario después de cambiar

u.admin = false
u.save!

:white_check_mark: funciona inmediatamente

Así que el problema es reproducible solo cuando admin == true.

Registro

El trabajador siempre se queda sin tiempo después de unos 30 segundos.

Rastreo:


GitUtils.try_git
GitUtils.has_commit?
DiscourseUpdates.new_features
DiscourseUpdates.has_unseen_features?
CurrentUserSerializer
ApplicationLayoutPreloader

El tiempo de espera siempre ocurre aquí:


/var/www/discourse/lib/git_utils.rb:33
Kernel#`

Observación importante

Ejecutar Git manualmente dentro del contenedor es instantáneo.

Por ejemplo:


git rev-parse HEAD

devuelve en unos 7 ms.

También:


git merge-base --is-ancestor <current_commit> HEAD

devuelve inmediatamente.

Así que Git en sí no es lento.

Redis

new_features no parece existir:


redis-cli exists new_features latest_new_feature_created_at

(integer) 0

Pregunta

¿Por qué GitUtils.has_commit? se bloquearía solo para usuarios administradores mientras cada comando Git se ejecuta instantáneamente desde la shell?

¿Hay algún problema conocido en versiones recientes de Discourse donde DiscourseUpdates o new_features cause tiempos de espera solo para administradores?

Cualquier idea sobre dónde investigar a continuación sería muy apreciada.

¡Gracias!