# Erreurs 502 spécifiques à l'utilisateur après la connexion — tracées à DiscourseUpdates.has\_unseen\_features?
**URL:** https://meta.discourse.org/t/user-specific-502-errors-after-login-traced-to-discourseupdates-has-unseen-features/394612
**Category:** Support
**Tags:** nginx, login, users
**Created:** [Janvier 28, 2026, 11:13 UTC](https://meta.discourse.org/t/user-specific-502-errors-after-login-traced-to-discourseupdates-has-unseen-features/394612 "2026-01-28T23:13:42Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@serkhelesheyi](https://meta.discourse.org/u/serkhelesheyi)
#### Post date: [Janvier 28, 2026, 11:13 UTC](https://meta.discourse.org/t/user-specific-502-errors-after-login-traced-to-discourseupdates-has-unseen-features/394612/1 "2026-01-28T23:13:42Z")
Bonjour,
Je rencontre un problème étrange avec mon Discourse où les **erreurs 502 ne se produisent que pour un compte utilisateur spécifique (administrateur) après la connexion**, alors que :
- Les utilisateurs anonymes peuvent accéder au site normalement
- D’autres comptes utilisateurs peuvent se connecter et utiliser le site normalement
- Le problème n’apparaît que pour **un compte spécifique (compte administrateur)**
* * *
### 🧩 Environnement
- Discourse installé via la **configuration Docker officielle**
- Proxy inverse / CDN : **ArvanCloud** (similaire à Cloudflare)
- L’accès à Internet international est **restreint / instable** (GitHub et certains services externes non accessibles)
- Discourse **n’a pas été mis à jour depuis environ 1 mois**
* * *
### ❗ Symptômes
Lors de l’accès au site :
- Si j’ouvre le site en **mode privé/incognito** → le site se charge correctement
- Si je me connecte avec mon **compte principal** → j’obtiens immédiatement une **erreur 502 Bad Gateway**
- Si je me connecte avec **un autre compte** → tout fonctionne bien
Le problème est donc clairement **spécifique à l’utilisateur et déclenché après l’authentification**.
* * *
### 📄 Journaux d’erreurs du CDN (ArvanCloud)
Deux erreurs principales apparaissent :
#### 1. Délai d’attente de la connexion en amont lors de la lecture de l’amont (Upstream timeout while reading upstream)
```plaintext
upstream timed out (110: Connection timed out) while reading upstream
```
Les URL affectées sont principalement des assets, par exemple :
- /assets/browser-detect-\*.js
- /assets/plugins/automation-\*.js
- /assets/plugins/discourse-gamification-\*.js
- /assets/plugins/discourse-lazy-videos-\*.js
#### 2. Connexion fermée prématurément par l’amont (Upstream prematurely closed connection)
```plaintext
upstream prematurely closed connection while reading response header from upstream
```
Par exemple :
- /stylesheets/common\_theme\_rtl\_\*.css
- /theme-javascripts/\*.js
Le CDN attend donc une réponse de Discourse, mais le backend expire ou ferme la connexion.
* * *
### 🔍 Ce que j’ai trouvé sur le backend
Dans les traces de pile Rails, le chemin de l’erreur pointe vers :
- `current_user_serializer.rb`
- `discourse_updates.rb`
- méthode : `DiscourseUpdates.has_unseen_features?`
Ce qui suggère que le crash/timeout se produit lors de la vérification des **annonces de nouvelles fonctionnalités pour les utilisateurs connectés**.
Puisque seul un utilisateur est affecté, cela suggère fortement que le problème est déclenché pendant la **sérialisation spécifique à l’utilisateur** , et non lors du rendu global du site.
* * *
Toute aide serait appréciée.
Merci beaucoup.
---
### Author:  [@Canapin](https://meta.discourse.org/u/Canapin)
#### Post date: [Janvier 28, 2026, 11:19 UTC](https://meta.discourse.org/t/user-specific-502-errors-after-login-traced-to-discourseupdates-has-unseen-features/394612/2 "2026-01-28T23:19:15Z")
> [@serkhelesheyi](#):
>
> - Si j’ouvre le site en **mode privé/incognito** → le site se charge correctement
Avez-vous essayé sur d’autres navigateurs/appareils ? Avez-vous essayé de désactiver les extensions de votre navigateur ?
Edit : Peut-être que j’ai mal compris. Le site se charge-t-il en mode incognito ET lorsque vous êtes connecté en tant qu’utilisateur ?
---
### Author:  [@serkhelesheyi](https://meta.discourse.org/u/serkhelesheyi)
#### Post date: [Janvier 28, 2026, 11:27 UTC](https://meta.discourse.org/t/user-specific-502-errors-after-login-traced-to-discourseupdates-has-unseen-features/394612/3 "2026-01-28T23:27:13Z")
Oui, j’ai testé sur plusieurs appareils et navigateurs, et cela n’est pas lié aux extensions de navigateur.
Ce que je constate est spécifique à l’utilisateur, pas à l’appareil :
- Sur tout appareil où le **compte administrateur était déjà connecté** , l’ouverture du site entraîne immédiatement une erreur **502 Bad Gateway**.
- En **mode incognito/privé** , le site se charge normalement et je peux atteindre la page de connexion.
- À partir de là, je peux me connecter avec succès avec un **autre compte (non administrateur)** et le site fonctionne bien.
- Mais lorsque j’essaie de me connecter avec le **compte administrateur** , juste après avoir soumis l’e-mail et le mot de passe, j’obtiens systématiquement **502** , et la page ne se charge jamais.
---
### Author:  [@kkurdupov](https://meta.discourse.org/u/kkurdupov)
#### Post date: [Avril 16, 2026, 8:37 UTC](https://meta.discourse.org/t/user-specific-502-errors-after-login-traced-to-discourseupdates-has-unseen-features/394612/4 "2026-04-16T08:37:33Z")
Nous avons rencontré le même problème et l’avons investigué plus en détail.
La cause racine est que `DiscourseUpdates.has_unseen_features?` appelle `GitUtils.has_commit?`, qui exécute :
```bash
git merge-base --is-ancestor HEAD
```
Dans les images Docker Discourse plus récentes, le dépôt à l’intérieur du conteneur est configuré comme un **clone partiel avec un remote promisor**. Lorsque le SHA de la fonctionnalité n’est pas présent localement, Git tente un fetch différé depuis le remote (`upload-pack`), ce qui prend environ 3 à 4 secondes par appel.
Comme plusieurs fonctionnalités sont vérifiées, cela se traduit par un temps de requête de plus de 30 secondes et finit par provoquer une erreur 502 (dépassement de délai Unicorn), en particulier pour les utilisateurs du personnel, pour qui cette vérification est effectuée.
Points clés :
- Se produit uniquement pour le personnel (via `CurrentUserSerializer`)
- Causé par l’absence de commits dans le clone partiel
- Les opérations Git sur des objets manquants déclenchent des recherches distantes lentes
- Reproductible via `git merge-base --is-ancestor HEAD` à l’intérieur du conteneur
Une mesure d’atténuation simple consiste à mettre en cache les résultats de `GitUtils.has_commit?` (par exemple, par combinaison HEAD+SHA), ce qui évite d’appeler à plusieurs reprises Git de manière coûteuse.