Erorile de publicare spun acum ce s-a întâmplat, în cuvinte simple
Când o publicare eșuează pe Mythex, dialogul îți spune acum într-o singură propoziție clară ce s-a întâmplat — build-ul a eșuat, aplicația ta s-a oprit după ce pornise, aplicația nu a pornit deloc, un fișier este prea mare sau ceva a mers prost la noi — și îți oferă Fix with AI și Try again. Rezultatul brut al build-ului și al aplicației tale ajunge în continuare la agent, astfel încât Fix with AI îl poate citi și repara proiectul, dar tu nu mai trebuie să îl citești.
Ce s-a schimbat
O propoziție pe care o poți folosi
Fiecare publicare eșuată are acum un tip, stabilit în momentul în care eșuează, pe baza faptelor pe care le avem atunci — ce pas a eșuat, dacă mașina aplicației a raportat blocări, dacă a început vreodată să accepte conexiuni — și nu prin citirea textului erorii după aceea. Fiecare tip are propriul mesaj:
| Ce vezi | Ce înseamnă |
|---|---|
| "The build failed." | Comanda de build sau Dockerfile-ul proiectului tău nu a reușit să construiască aplicația. |
| "Your app stopped right after it started." | Aplicația a fost publicată, apoi s-a oprit sau a tot repornit. |
| "Your app didn't start after publishing." | Aplicația a fost publicată, dar nu a început niciodată să accepte conexiuni. |
| "This file is too big" / prea multe fișiere | Un site static depășește limita de dimensiune per fișier sau de număr de fișiere. Mesajul listează fișierele. |
| "This link name can't be used for publishing." | Schimbă numele linkului și publică din nou; codul tău este în regulă. |
| "Publishing is busy for a moment" | Nimic nu este în neregulă cu aplicația ta. Publică din nou peste câteva minute. |
| "…a problem on our side, not in your app." | Problema este la noi, de rezolvat de noi. Publică din nou peste câteva minute. |
Fix with AI la fiecare eșec
Fiecare eșec afișează Fix with AI și Try again. Când folosești Fix with AI, agentul primește tipul eșecului și rezultatul complet al build-ului sau al aplicației, în mod privat, în propriul context. Dacă ceva din aplicația ta este greșit, îl repară. Dacă nu este nimic greșit — un moment de aglomerație sau o problemă de partea noastră — poate pur și simplu să publice din nou. Nu trebuie să îți dai seama tu ce fel de eșec a fost.
Probleme după ce aplicația este live
O publicare poate reuși, iar aplicația să cadă câteva minute mai târziu. Mythex verifică regulat aplicațiile publicate. Dacă o aplicație live se blochează în continuare sau rulează, dar nu mai acceptă conexiuni, publicarea este marcată ca eșuată, primești un e-mail, iar proiectul afișează mesajul împreună cu Fix with AI. Ce a afișat aplicația este salvat, ca agentul să îl poată citi.
Limite de dimensiune verificate înainte de încărcare
Pentru site-urile statice, dimensiunea fiecărui fișier și numărul total de fișiere sunt verificate înainte ca ceva să fie încărcat. Dacă ceva depășește limita, primești un singur mesaj care listează fiecare fișier prea mare, în loc de un eșec la jumătatea procesului.
De ce l-am construit
Înainte, un eșec de publicare arăta orice afișaseră uneltele din spatele publicării. Timp de o săptămână, la sfârșitul lui septembrie, cele mai multe eșecuri afișau texte ale furnizorilor de build care erau de competența noastră, nu a lor: contacte de facturare, numere interne de versiune, căi de registru, erori de stocare. Fix with AI lipea apoi același text în chat. Oamenii erau puși să depaneze infrastructura noastră.
Unele dintre ele erau pur și simplu greșite. O aplicație care nu asculta pe portul ei era raportată drept „a problem on our side”, deși remedierea era în aplicație. Un fișier static peste limită era raportat la fel — iar republicarea nu ar fi putut funcționa niciodată.
Și fiecare parte din Mythex care reacționa la un eșec — dialogul, notificările, Fix with AI, alertele noastre — își dădea seama ce s-a întâmplat potrivind cuvinte din textul erorii. Asta se strica ori de câte ori se schimba formularea. Acum tipul este înregistrat acolo unde apare eșecul, iar tot restul citește tipul.
Am aplicat aceeași regulă și altor erori, cât eram acolo:
- Chat. Dacă conexiunea se întrerupe în timp ce un răspuns este transmis, vezi acum propoziția noastră, în loc de "Load failed" sau "Failed to fetch" din browser.
- Domenii personalizate. Mesajele despre cumpărarea sau conectarea unui domeniu sunt alese acum după statusul și codurile răspunsului, în loc să preia propozițiile furnizorului de domenii.
- Generarea de imagini. Cardul afișează mesajul nostru; agentul primește detaliul serviciului.
Cum îl folosești
- Publică în mod obișnuit, din butonul Publish.
- Dacă eșuează, citește mesajul de o linie din dialog.
- Apasă Fix with AI. Agentul citește rezultatul build-ului sau jurnalele aplicației tale, repară ce este greșit și republică dacă nimic din aplicație nu trebuia reparat.
- Sau apasă Try again ca să publici din nou aceeași versiune — alegerea potrivită pentru "Publishing is busy for a moment" și pentru "…a problem on our side".
- Dacă mesajul este despre numele linkului, schimbă numele linkului înainte de a publica din nou. Pentru orice altă eroare, păstrează același nume.
Limite
- Unele eșecuri afișează alte butoane: un nume de link deja luat sugerează alte nume, iar lipsa de credite oferă o cale de a adăuga credite.
- Site-urile statice au o limită per fișier de aproximativ 25–30 MB, în funcție de tipul site-ului, și până la 20.000 de fișiere. Fișierele mari sunt mai bine păstrate în stocare și legate de site.
- Publicările eșuate dinaintea acestei schimbări nu au un tip, așa că afișează o linie neutră, nu un motiv specific.
- Dacă "…a problem on our side" se repetă, contactează suportul cu ID-ul proiectului și numele linkului.
Lista completă a mesajelor și ce trebuie făcut pentru fiecare este în depanarea publicării. Dacă repari manual o aplicație încăpățânată, ghidul nostru despre cum depanezi o aplicație construită cu AI parcurge pașii. Iar pentru ce se întâmplă cu un site live cât timp îl republici, vezi aplicația ta publicată rămâne activă în timp ce o republici.