GitHub accumule les bugs de comptage et les incohérences d'interface
En bref
- Un utilisateur signale des bugs sévères sur GitHub : comptage inexact des pull requests dans les onglets de dépôt, et pagination cassée lors de la sélection d'organisations.
- Le fil HN révèle des problèmes bien plus larges : désynchronisation entre la base de données principale et l'index Elasticsearch, inconsistance de l'API (résultats différents à quelques secondes d'intervalle), et PRs approuvées affichées en attente de review pendant des semaines.
- Les commentaires pointent une dégradation générale de la fiabilité et de la performance depuis l'acquisition par Microsoft, particulièrement accélérée par le rush sur les features IA.
Ce que dit la source
L'auteur décrit deux bugs distincts rencontrés cette semaine : un comptage erroné des PRs dans l'onglet du dépôt (particulièrement après fusion), et une pagination cassée pour l'organisations lors de la sélection dans les pop-ups de configuration (obligeant à utiliser la console JavaScript pour naviguer). Il note qu'une majorité des bugs semblent survenir après des actions comme les fusions de PR.
- Le comptage des PRs dans les onglets reste inexact même après rechargement, le nombre correct s'affichant ailleurs sur la même page
- L'API GitHub Actions retourne des résultats inconsistants : le même appel filtre retourne 3, puis 2, puis à nouveau 3 workflow runs quelques secondes plus tard
- Plusieurs commentateurs signalent des PRs approuvées restant affichées en attente de review pendant des semaines, bloquant involontairement les deployments
- Un commentateur a pu voir le comptage d'issues de dépôts privés auxquels il n'avait pas accès, révélant une faille de sécurité potentielle
- La cause probable identifiée : désynchronisation entre la base de données principale et l'index Elasticsearch, aggravée par la migration récente vers une recherche systématique incluant les filtres basiques
- Certains anciens PRs (8+ ans) deviennent invisibles en recherche et navigation paginée, bien que les liens directs restent fonctionnels
Dans les commentaires
Débat largement critique, convergent : GitHub est perçu comme devenu instable et peu fiable depuis l'acquisition par Microsoft. Peu de défense substantielle, plutôt des témoignages accumulés d'un déclin de qualité.
- Un commentateur établit un parallèle avec Skype, également dégradé après acquisition par Microsoft, suggérant un problème systémique d'intégration chez Microsoft plutôt qu'une cause technique isolée
- La théorie de la désynchronisation database/search (commentaire [7]) fournit une explication technique crédible ; elle remonte à une migration stratégique de GitHub pour centraliser tout sur la recherche
- Un commentateur soulève un problème d'architecture plus large : trop d'indirection entre l'état réel du système et ce que voit l'utilisateur, générant de la complexité et des incohérences
- Plusieurs commentaires signalent des impacts business directs (PRs bloquées en review fantôme, fuites de données privées entre orgs), pas juste des annoyances cosmétiques
Alternatives citées : GitLab et Gitea sont implicitement désignés comme alternatives dans plusieurs commentaires critiques envers Microsoft, bien que non explicitement nommés comme solutions de remplacement directes dans le fil fourni.
Notre lecture
GitHub souffre d'un problème architectural visible : sa migration vers Elasticsearch pour les recherches et listes ne se synchronise pas proprement avec la source de vérité. Ces bugs ne sont pas anecdotiques ; ils affectent des workflows critiques (review de PR, permissions) et la fiabilité perçue du service. Pour les DSI et tech leads, cela milite pour tester une alternative (Gitea, GitLab self-hosted) si GitHub est un point de défaillance inacceptable. À court terme, recharger les pages de comptage reste une contournement pragmatique, mais l'accumulation de ces problèmes couplée à l'inertie perçue chez Microsoft en matière de correction est un signal d'alerte légitime.