Les erreurs de publication disent désormais ce qui s'est passé, en clair
Lorsqu'une publication échoue sur Mythex, la fenêtre vous indique désormais en une phrase claire ce qui s'est passé : le build a échoué, votre app s'est arrêtée juste après son démarrage, elle n'a jamais démarré, un fichier est trop volumineux, ou quelque chose a mal tourné de notre côté. Elle propose Fix with AI et Try again. La sortie brute du build et de votre app parvient toujours à l'agent, pour qu'il puisse la lire et corriger le projet, mais vous n'avez plus à la lire vous-même.
Ce qui a changé
Une phrase exploitable
Chaque publication échouée a maintenant un type, déterminé au moment de l'échec à partir de faits disponibles à cet instant (quelle étape a échoué, si la machine de l'app a signalé des plantages, si elle a jamais accepté des connexions), et non en lisant après coup le texte de l'erreur. Chaque type a son propre message :
| Ce que vous voyez | Ce que cela signifie |
|---|---|
| « The build failed. » | La commande de build ou le Dockerfile de votre projet n'a pas abouti. |
| « Your app stopped right after it started. » | L'app a été publiée, puis s'est arrêtée ou redémarre en boucle. |
| « Your app didn't start after publishing. » | L'app a été publiée mais n'a jamais commencé à accepter de connexions. |
| « This file is too big » / trop de fichiers | Un site statique dépasse la limite de taille par fichier ou de nombre de fichiers. Le message liste les fichiers. |
| « This link name can't be used for publishing. » | Changez le nom du lien et publiez à nouveau ; votre code est correct. |
| « Publishing is busy for a moment » | Rien ne cloche dans votre app. Publiez à nouveau dans quelques minutes. |
| « …a problem on our side, not in your app. » | C'est à nous de le corriger. Publiez à nouveau dans quelques minutes. |
Fix with AI sur chaque échec
Chaque échec affiche Fix with AI et Try again. Lorsque vous utilisez Fix with AI, l'agent reçoit en privé le type d'échec et la sortie complète du build ou de l'app, dans son propre contexte. Si quelque chose ne va pas dans votre app, il le corrige. Si rien ne cloche, comme un moment d'occupation ou un problème de notre côté, il peut simplement publier à nouveau. Vous n'avez pas à deviner de quel type d'échec il s'agissait.
Problèmes après la mise en ligne
Une publication peut réussir et l'app échouer quelques minutes plus tard. Mythex vérifie régulièrement les apps publiées. Si une app en ligne plante à répétition, ou tourne sans accepter de connexions, la publication est marquée comme échouée, vous recevez un e-mail, et le projet affiche le message avec Fix with AI. Ce que l'app a affiché est conservé pour que l'agent le lise.
Limites de taille vérifiées avant l'envoi
Pour les sites statiques, la taille de chaque fichier et le nombre total de fichiers sont vérifiés avant tout envoi. Si quelque chose dépasse, vous recevez un seul message listant chaque fichier trop volumineux, au lieu d'un échec en cours de route.
Pourquoi nous l'avons fait
Un échec de publication affichait autrefois ce que les outils de publication avaient imprimé. Pendant une semaine à la fin septembre, la plupart des échecs montraient aux constructeurs des textes qui relevaient de nous et non d'eux : contacts de facturation, numéros de version internes, chemins de registre, erreurs de stockage. Fix with AI collait alors ce même texte dans le chat. On demandait aux gens de déboguer notre infrastructure.
Une partie de ce texte était aussi tout simplement fausse. Une app qui n'écoutait jamais sur son port était présentée comme « un problème de notre côté », alors que la correction se trouvait dans l'app. Un fichier statique au-delà de la limite de taille était signalé de la même façon, alors que publier à nouveau ne pouvait jamais fonctionner.
Et chaque partie de Mythex qui réagissait à un échec (la fenêtre, les notifications, Fix with AI, nos propres alertes) déterminait ce qui s'était passé en repérant des mots dans le texte de l'erreur. Cela cassait dès que la formulation changeait. Désormais, le type est enregistré à l'endroit où l'échec se produit, et tout le reste lit ce type.
Nous avons appliqué la même règle à d'autres erreurs au passage :
- Chat. Si la connexion se coupe pendant que la réponse s'affiche en flux, vous voyez notre phrase au lieu du « Load failed » ou « Failed to fetch » du navigateur.
- Domaines personnalisés. Les messages concernant l'achat ou la connexion d'un domaine sont désormais choisis selon le statut et les codes de la réponse, au lieu de transmettre les phrases du fournisseur de domaines.
- Génération d'images. La carte affiche notre message ; l'agent reçoit le détail du service.
Comment l'utiliser
- Publiez comme d'habitude depuis le bouton Publish.
- En cas d'échec, lisez le message d'une ligne dans la fenêtre.
- Cliquez sur Fix with AI. L'agent lit la sortie du build ou les logs de votre app, corrige ce qui ne va pas, et republie si rien dans l'app n'avait besoin de correction.
- Ou cliquez sur Try again pour publier à nouveau la même version, le bon choix pour « busy for a moment » et « a problem on our side ».
- Si le message concerne le nom du lien, changez-le avant de publier à nouveau. Pour toute autre erreur, gardez le même nom.
Limites
- Certains échecs affichent d'autres boutons : un nom de lien déjà pris suggère d'autres noms, et un solde de crédits épuisé propose d'ajouter des crédits.
- Les sites statiques ont une limite d'environ 25 à 30 Mo par fichier, selon le type de site, et jusqu'à 20 000 fichiers. Les gros fichiers sont mieux placés dans le stockage et liés depuis votre site.
- Les publications échouées antérieures à ce changement n'ont pas de type ; elles affichent donc une ligne neutre plutôt qu'une raison précise.
- Si « a problem on our side » revient sans cesse, contactez le support avec l'identifiant du projet et le nom du lien.
La liste complète des messages et ce qu'il faut faire pour chacun se trouve dans le dépannage de publication. Si vous corrigez à la main une app récalcitrante, notre guide comment déboguer une app construite avec l'IA explique la démarche. Et pour ce qui arrive à un site en ligne pendant que vous le republiez, voir votre app publiée reste désormais en ligne pendant sa republication.