Il semble que récemment, les utilisateurs qui s’inscrivent (edit: ou peut-être qui ont juste l’« avatar système » mais qui n’est pas mis en cache dans mon navigateur) n’obtiennent pas l’avatar système typique avec des caractères colorés, mais plutôt une image blanche / vide. Dans certains cas, il semble qu’il se charge, se rafraîchissant de manière asynchrone. Je vois cela sur mon instance, mais aussi ici :
Edit :
Il semble que le problème de l’avatar renvoie parfois une erreur 502.
Un incendie/une explosion à proximité du centre de données où est hébergé le service d’avatar a provoqué la panne. Nous travaillons à rétablir tous les services.
Merci pour la mise à jour.
Existe-t-il une page de statut du centre de données pour suivre nous-mêmes l’incident ?
Et est-ce seulement nous qui avons des rapports d’administration qui ne fonctionnent pas ?
Je ne constate aucun problème avec les rapports d’administration sur nos sites.
Vous pouvez suivre l’incident sur notre page d’état à l’adresse https://status.discourse.org/
J’ai constaté le même problème (les rapports d’administration ne se chargent pas) ce matin. Les journaux indiquent de nombreuses erreurs de délai d’attente dans le service proxy d’avatar et le travail de vérification de version. Je me demande si cela retarde d’autres tâches d’arrière-plan, y compris la génération de rapports.
Le fait que les avatars soient proxysés via nginx, et que ceux-ci prennent maintenant 15 secondes à expirer au lieu de millisecondes à charger, peut dans certaines circonstances saturer gravement votre capacité nginx, entraînant des erreurs dans d’autres requêtes non liées.
Il semble utile de désactiver temporairement Admin - Settings - Files - external_system_avatars_enabled. (merci @gerhard)
Merci à tous. Je transmets ceci à notre équipe d’administration système pour qu’elle vérifie ce qui pourrait causer des erreurs de reporting et si la solution temporaire que vous avez fournie doit être appliquée dans notre cas.
Il m’a fallu un certain temps pour réaliser qu’il s’agissait d’un forum. Je peux signaler que la désactivation du service d’avatar externe n’aide pas les modules du tableau de bord d’administration à se charger.
Le service central des avatars devrait maintenant être de retour en ligne 
Il m’intéresse que notre instance auto-hébergée ait souffert de nombreux problèmes aléatoires pendant ce problème, en plus de celui évident de la non-chargement des avatars… Désactiver le « service d’avatar externe » dans les paramètres n’a pas non plus aidé — les avatars ne se sont alors pas affichés du tout, et les appels API ont toujours bloqué pendant longtemps avant d’échouer. Je pensais que notre instance était plus ou moins indépendante, ou pouvait l’être, mais apparemment pas.
Basculer le paramètre supprimera la dépendance vis-à-vis du service central, mais cela nécessitera une régénération complète de tous les messages pour mettre à jour toutes les URL d’avatar mises en cache.
Vous avez tout à fait raison, une panne du service d’avatar de lettres ne devrait pas affecter le reste du site. Comme l’a noté @RGJ, cela semble être lié à la capacité de NGINX lorsque les requêtes proxy bloquent pendant longtemps - nous examinerons certainement s’il est possible d’y apporter des améliorations.
