Depuis quelques semaines, le bouton « Commencer la mise à niveau » s’affiche juste après que la mise à niveau a été terminée.
À mon avis, il s’agit d’un bug, car avant ce changement, aucun bouton ne permettait de relancer la mise à niveau.
Je suggère de faire disparaître le bouton après une mise à niveau ou, à tout le moins, de le désactiver.
J’ai effectué une mise à niveau hier pour obtenir la version la plus récente.
Aujourd’hui, j’ai à nouveau effectué une mise à niveau et je vois toujours cet écran :
Serait-il possible que mon bloqueur de publicités en soit la cause ?
En examinant la console du navigateur après la mise à niveau, j’ai constaté deux entrées :
/message-bus/fc3f44b30aea4975be751a4cc8736f76/poll:1 Échec du chargement de la ressource : net::ERR_HTTP2_PROTOCOL_ERROR
docker/upgrade:1 Échec du chargement de la ressource : le serveur a répondu avec un statut 504 ()
Je constate la même chose. En effet, quelle que soit la transformation du bouton « Démarrer la mise à niveau » une fois celle-ci lancée — je pense qu’il se transformait autrefois en un bouton d’annulation quelconque — j’ai remarqué qu’il revenait assez rapidement à « Démarrer la mise à niveau » alors que la mise à niveau était toujours en cours, et il est resté ainsi même après l’achèvement réussi de la mise à niveau. J’utilise Chrome Version 86.0.4240.80 (Version officielle) (x86_64) sur un Mac.
J’ai observé ce comportement lors d’une précédente mise à niveau. La mise à niveau actuelle passe de 2.6.0.beta3 à 2.6.0.beta4. Je pense que la mise à niveau immédiatement précédente nécessitait une reconstruction de l’application.
Édition : sur mon autre forum, je viens de voir la même chose et j’ai pris quelques captures d’écran. Le bouton est revenu en arrière alors que le journal affichait encore l’un des nombreux messages « En attente du rechargement de Unicorn » au début. (Je suppose que ce retour est basé sur le temps écoulé, et non sur l’avancement de la mise à niveau. Édition : 60 secondes entre l’appui sur le bouton et le retour à l’état initial. Alors que la barre de progression a bougé pour la première fois vers 90 secondes.) Voir ci-dessous :
Toujours pas résolu pour moi non plus.
J’ai rencontré cette chose étrange il y a quelques jours. Cela m’a un peu perturbé.
Redémarrer la machine (peut-être simplement le conteneur Docker) ou redémarrer Redis devrait régler le problème, je pense. Nous n’avons pas d’étapes de reproduction claires pour cela, mais je l’ai également observé, donc cela se produit bel et bien.
C’est surtout cosmétique, donc pas une priorité élevée. Si nous avions des étapes de reproduction claires et cohérentes…
J’ai mis à niveau sept instances la semaine dernière vers la dernière version bêta (les tests ont réussi), et toutes ont présenté le problème.
Eh bien, cela pourrait être une régression alors, cc @eviltrout
J’ai réussi à reproduire le problème. Le code client n’a pas changé de manière significative. Il semble que le problème vienne du fait qu’un appel à /admin/docker/upgrade déclenche désormais un délai d’expiration de passerelle 504.
Notre gestionnaire d’erreurs lui indique alors de marquer son état comme « non en cours de mise à niveau », ce qui signifie que lorsque la notification de complétion du bus de messages arrive, elle n’est pas marquée comme terminée.
À mon avis, la cause racine ici est le délai d’expiration 504 que nous n’avions pas observé auparavant. Je soupçonne une modification liée à un proxy ou à Rails. Peut-être quelque chose dans notre image Docker ? @sam, êtes-vous au courant de quelque chose ou pouvez-vous peut-être assigner cela à l’équipe DevOps ?
Je remarque certains comportements étranges côté client qui provoquent une certaine surprise :
Pourquoi effectuons-nous des requêtes HTTP vers le serveur pendant la mise à niveau ? Il semble que nous fassions une requête vers /admin/docker/upgrade en plein milieu de la mise à niveau, ce qui me paraît confus. Nous devrions simplement attendre le message sur le bus. J’ai exécuté cela dans Firefox, donc mes possibilités de débogage sont limitées.
Le messagebus ne fait pas de longue attente (long polling), mais uniquement de courte attente (short polling), ce qui entraîne des limites de taux.
« Passer à la prochaine mise à niveau » est un peu confus ; nous devrions simplement indiquer « terminé » une fois qu’une partie de la mise à niveau est achevée, plutôt que de vous basculer rapidement vers l’autre partie.
@Osama, peux-tu consacrer un peu de temps au débogage, à l’affinement et à la mise à niveau d’Ember, etc. ? Je pense que la majorité des problèmes ici semblent relever du travail côté client.
Note pour les personnes suivant ce sujet : nous allons régler cela, mais cela prendra probablement 2 à 4 semaines. Comme cela dure déjà depuis un mois, je pense que nous pouvons attendre un peu.
Je n’ai jamais vu cela – fait-il partie de « Mettre tout à niveau » ?
Cela me convient, bien sûr. J’ai cru voir quelqu’un dire qu’il avait accidentellement cliqué sur « Démarrer la mise à niveau » lorsque l’option est réapparue – espérons que cela soit sans danger. Je n’ai jamais utilisé « Réinitialiser la mise à niveau », mais je suppose que c’est une fonction de sécurité au cas où la mise à niveau resterait bloquée.
Je me souviens avoir signalé le même problème il y a probablement plus d’un mois, donc il est présent depuis un certain temps.
J’ai intégré une correction pour ce bug :
Une fois que vous aurez mis à jour docker_manager, ce bug devrait être résolu pour les futures mises à jour.
Ce sujet a été automatiquement fermé après 3 jours. De nouvelles réponses ne sont plus autorisées.
