Bonjour,

Mon service chic-reverence (project ID: 17854db4-b5b1-4e67-aaf8-27d44ea434d9, service ID: 5a7a8091-e881-45fc-bf11-d4f31abe8581, environment ID: 43bef730-db0d-465c-9ee7-ddd82d693608) semble bloqué sur un ancien conteneur malgré plusieurs déploiements marqués "Success"/"Active".

Contexte : le domaine public est senzasmartapp.com, et le sous-domaine généré est chic-reverence-production-a0d0.up.railway.app. Le service sert un fichier statique (privacy.html) via un petit serveur Node (server.js) qui lit le fichier directement depuis le disque à chaque requête (fs.readFile, aucun cache applicatif).

Ce que j'ai modifié : j'ai commité un changement dans privacy.html sur la branche main du dépôt GitHub connecté (rachzzr-hash/senza-smart-app-website), commit f23a1267ccd05e87d250223edb7d42c96c44cb47 ("Update privacy.html"), le 29 septembre 2026.

Ce que j'ai déjà essayé, sans succès :

Plusieurs redéploiements manuels (avant et après votre incident du 29 septembre concernant des "slow or stuck deployments", statut désormais "Resolved").

Déconnexion/reconnexion complète de l'intégration GitHub.

Vérification qu'aucun Volume n'est attaché au service.

Vérification que "Root Directory" est vide (build depuis la racine du repo).

Vérification de la branche connectée (une seule branche existe sur le repo).

Les Build Logs montrent une étape copy / /app non mise en cache (658ms), donc le build semble bien recopier le contenu à jour.

Symptôme : malgré tout ça, https://chic-reverence-production-a0d0.up.railway.app/privacy continue de servir l'ancien contenu du fichier, identique avant et après chaque redéploiement, testé à la fois via requêtes HTTP directes et via un vrai navigateur (donc pas un problème de cache client).

Pouvez-vous vérifier si le conteneur réellement actif derrière ce service correspond bien au dernier build, ou s'il existe un conteneur/replica bloqué depuis l'incident du 29 septembre ? Un redémarrage forcé côté infrastructure serait très apprécié si c'est possible.

Merci d'avance,

Rachid