Грешките при објавување сега јасно кажуваат што се случило
Кога објавувањето на Mythex ќе не успее, дијалогот сега во една јасна реченица ви кажува што се случило — билдот не успеал, апликацијата застанала откако се објавила, апликацијата не се стартувала по објавувањето, датотеката е преголема или нешто е проблем на наша страна — и ви нуди Fix with AI и Try again. Сировиот излез од билдот и од вашата апликација сè уште стига до агентот, па Fix with AI може да го прочита и поправи проектот, но вие повеќе не мора сами да го читате.
Што се промени
Една реченица што можете да ја искористите
Секое неуспешно објавување сега има тип, одреден во моментот на неуспехот од податоците што ги имаме таму — кој чекор не успеал, дали машината на апликацијата пријавила падови, дали воопшто почнала да прима врски — наместо тоа да се одредува со читање на текстот на грешката подоцна. Секој тип има своја порака:
| Што гледате | Што значи |
|---|---|
| „The build failed.“ | Командата за билд или Dockerfile во вашиот проект не успеала да изгради. |
| „Your app stopped right after it started.“ | Се објавила, а потоа излегла или продолжила да се рестартира. |
| „Your app didn't start after publishing.“ | Се објавила, но никогаш не почнала да прима врски. |
| „This file is too big“ / премногу датотеки | Статичко мрежно место е над лимитот по големина на датотека или по број датотеки. Пораката ги наведува датотеките. |
| „This link name can't be used for publishing.“ | Променете го името на линкот и објавете повторно; вашиот код е во ред. |
| „Publishing is busy for a moment“ | Со вашата апликација нема проблем. Објавете повторно за неколку минути. |
| „…a problem on our side, not in your app.“ | Наша одговорност е да го решиме. Објавете повторно за неколку минути. |
Fix with AI при секој неуспех
Секое неуспешно објавување прикажува Fix with AI и Try again. Кога ќе користите Fix with AI, агентот го добива типот на неуспехот и целиот излез од билдот или апликацијата приватно, во сопствениот контекст. Ако нешто во вашата апликација е погрешно, тој го поправа. Ако ништо не е, на пример зафатен момент или проблем на наша страна, може едноставно повторно да објави. Не мора вие да откриете од кој тип неуспех станува збор.
Проблеми по објавувањето
Објавувањето може да успее, а апликацијата да падне неколку минути подоцна. Mythex редовно ги проверува објавените апликации. Ако една жива апликација постојано се урива или продолжува да работи, но престанува да прима врски, објавувањето се означува како неуспешно, добивате е-пошта, а проектот ја прикажува пораката со Fix with AI. Она што го испечатила апликацијата се зачувува за агентот да го прочита.
Проверка на лимитите пред качување
За статички мрежни места, големината на секоја датотека и вкупниот број датотеки се проверуваат пред да се качи било што. Ако нешто е над лимитот, добивате една порака со сите датотеки што се преголеми, наместо неуспех на половина пат.
Зошто го направивме тоа
Неуспешното објавување порано ги прикажуваше сите излези што ги испечатија алатките зад објавувањето. Во една недела кон крајот на септември, повеќето неуспеси прикажуваа текст од билдерите што беше наша одговорност, а не на корисниците: billing контакти, внатрешни верзии, патеки до регистар, грешки при складирање. Fix with AI тој текст го залепуваше директно во разговорот. Од луѓето се бараше да дебагираат наша инфраструктура.
Дел од тој текст беше и едноставно погрешен. Апликација што не слушаше на својот порт беше пријавена како „a problem on our side“, иако поправката беше во самата апликација. Статичка датотека над лимитот беше пријавена на ист начин — а повторното објавување никогаш не би успеало.
И секој дел од Mythex што реагираше на неуспех — дијалогот, известувањата, Fix with AI, нашите сопствени алармови — порано дознаваше што се случило со совпаѓање на зборови во текстот на грешката. Тоа се расипуваше секогаш кога ќе се промени формулацијата. Сега типот се запишува на местото каде што се случува неуспехот, а сè останато го чита типот.
Истото правило го применивме и на други грешки додека бевме тука:
- Разговор. Ако врската се прекине додека одговорот се стримува, сега ја гледате нашата реченица наместо „Load failed“ или „Failed to fetch“ од прелистувачот.
- Кориснички домени. Пораките за купување или поврзување домен сега се избираат според статусот и кодовите на одговорот, наместо да се пренесуваат реченици од давателот на доменот.
- Генерирање слики. Картичката ја прикажува нашата порака; агентот ја добива деталната порака од сервисот.
Како да го користите
- Објавете како и порано од копчето Publish.
- Ако не успее, прочитајте ја еднореченичната порака во дијалогот.
- Кликнете Fix with AI. Агентот го чита излезот од билдот или логовите на апликацијата, ја поправа грешката и повторно објавува ако ништо во апликацијата не требаше поправка.
- Или кликнете Try again за да ја објавите истата верзија повторно — вистинскиот избор за „busy for a moment“ и „a problem on our side“.
- Ако пораката е за името на линкот, променете го името пред повторно објавување. За која било друга грешка, задржете го истото име.
Ограничувања
- Некои неуспеси прикажуваат различни копчиња: зафатено име на линк предлага други имиња, а кога ќе снемаат кредитите се нуди додавање кредити.
- Статичките мрежни места имаат лимит по датотека од околу 25–30 MB, во зависност од видот на местото, и до 20.000 датотеки. Големите датотеки подобро е да се чуваат во складиштето и да се поврзуваат.
- Неуспешните објавувања пред оваа промена немаат тип, па прикажуваат неутрален ред наместо конкретна причина.
- Ако „a problem on our side“ продолжи да се појавува, контактирајте ја поддршката со ID на проектот и името на линкот.
Целосниот список на пораки и што да се направи за секоја е во решавање проблеми при објавување. Ако рачно поправате упорна апликација, нашиот водич за како да дебагирате апликација направена со AI ги опфаќа чекорите. А за она што се случува со живото мрежно место додека го објавувате повторно, погледнете вашата објавена апликација сега останува активна додека ја објавувате повторно.