Publish की त्रुटियाँ अब सादे शब्दों में बताती हैं कि क्या हुआ
Mythex पर publish विफल होने पर डायलॉग अब एक सादे वाक्य में बताता है कि क्या हुआ: build विफल हुआ, आपका ऐप शुरू होने के बाद रुक गया, ऐप शुरू ही नहीं हुआ, कोई फ़ाइल बहुत बड़ी है, या हमारी तरफ़ कुछ गलत हुआ। और यह Fix with AI और Try again देता है। Build और आपके ऐप का कच्चा आउटपुट अब भी एजेंट तक पहुँचता है, ताकि Fix with AI उसे पढ़कर प्रोजेक्ट ठीक कर सके, पर आपको उसे खुद पढ़ने की ज़रूरत नहीं।
क्या बदला
एक वाक्य जिस पर आप कार्रवाई कर सकें
हर विफल publish का अब एक प्रकार है, जो विफल होने के क्षण पर वहीं मौजूद तथ्यों से तय होता है: कौन-सा कदम विफल हुआ, ऐप की मशीन ने क्रैश रिपोर्ट किए या नहीं, और ऐप कभी कनेक्शन लेने लगा या नहीं। यह बाद में error text पढ़कर नहीं तय होता। हर प्रकार का अपना संदेश है:
| आप क्या देखते हैं | इसका मतलब |
|---|---|
| "The build failed." | आपके प्रोजेक्ट का build command या Dockerfile नहीं बना। |
| "Your app stopped right after it started." | यह publish हुआ, फिर बंद हुआ या बार-बार restart होता रहा। |
| "Your app didn't start after publishing." | यह publish हुआ, पर कनेक्शन लेना शुरू ही नहीं किया। |
| "This file is too big" / बहुत सारी फ़ाइलें | एक स्टैटिक साइट प्रति-फ़ाइल आकार या फ़ाइल-गिनती की सीमा से ऊपर है। संदेश फ़ाइलों की सूची देता है। |
| "This link name can't be used for publishing." | link name बदलें और दोबारा publish करें; आपका कोड ठीक है। |
| "Publishing is busy for a moment" | आपके ऐप में कुछ गलत नहीं है। कुछ मिनट बाद फिर publish करें। |
| "…a problem on our side, not in your app." | हमारी ओर का मामला है। हम ठीक करेंगे। कुछ मिनट बाद फिर publish करें। |
हर विफलता पर Fix with AI
हर विफलता पर Fix with AI और Try again दिखते हैं। जब आप Fix with AI इस्तेमाल करते हैं, तो एजेंट को विफलता का प्रकार और पूरा build या ऐप आउटपुट निजी रूप से, अपने संदर्भ में, मिलता है। अगर आपके ऐप में कुछ गलत है, तो वह उसे ठीक करता है। अगर कुछ गलत नहीं है, जैसे व्यस्त क्षण या हमारी ओर की समस्या, तो वह बस फिर से publish कर सकता है। आपको यह तय नहीं करना पड़ता कि विफलता किस तरह की थी।
लाइव होने के बाद की समस्याएँ
Publish सफल हो सकता है और ऐप कुछ मिनट बाद विफल हो सकता है। Mythex publish किए गए ऐप्स की नियमित जाँच करता है। अगर कोई लाइव ऐप लगातार क्रैश होता है, या चलता रहता है पर कनेक्शन लेना बंद कर देता है, तो publish को विफल चिह्नित किया जाता है, आपको ईमेल मिलता है, और प्रोजेक्ट में संदेश Fix with AI के साथ दिखता है। ऐप ने जो प्रिंट किया, वह एजेंट के पढ़ने के लिए सेव रहता है।
अपलोड से पहले आकार की जाँच
स्टैटिक साइट्स के लिए, कुछ भी अपलोड होने से पहले हर फ़ाइल का आकार और कुल फ़ाइल-गिनती जाँची जाती है। अगर कुछ सीमा से बड़ा है, तो आपको एक संदेश मिलता है जिसमें हर बहुत बड़ी फ़ाइल की सूची होती है, बजाय इसके कि बीच में कहीं विफल हो।
हमने यह क्यों बनाया
विफल publish पहले वही दिखाता था जो publish के पीछे के tools ने प्रिंट किया था। सितंबर के अंत के एक हफ़्ते में, ज़्यादातर विफलताएँ बिल्डर को ऐसा टेक्स्ट दिखा रही थीं जो हमारी ज़िम्मेदारी थी, उनकी नहीं: billing contacts, आंतरिक version numbers, registry paths, storage errors। Fix with AI वही टेक्स्ट चैट में चिपका देता था। लोगों से हमारे infrastructure को डीबग करने को कहा जा रहा था।
उसमें से कुछ सीधे गलत भी था। वह ऐप जो अपने पोर्ट पर कभी सुना ही नहीं, उसे "हमारी तरफ़ की समस्या" बताया गया, जबकि ठीक करना ऐप के भीतर था। एक स्टैटिक फ़ाइल जो सीमा से बड़ी थी, उसे भी वैसे ही बताया गया, और दोबारा publish करने से वह कभी काम नहीं कर सकती थी।
और Mythex का हर हिस्सा जो विफलता पर प्रतिक्रिया देता था, जैसे डायलॉग, सूचनाएँ, Fix with AI, हमारे अपने alerts, error text में शब्द मिलाकर पता करता था कि क्या हुआ। जब भी शब्द बदलते, वह टूट जाता था। अब प्रकार वहीं दर्ज होता है जहाँ विफलता होती है, और बाकी सब उसी प्रकार को पढ़ते हैं।
जब हम वहाँ थे तो हमने यही नियम दूसरी त्रुटियों पर भी लागू किया:
- Chat। अगर जवाब स्ट्रीम होते समय कनेक्शन टूटे, तो अब आप हमारा वाक्य देखते हैं, browser का "Load failed" या "Failed to fetch" नहीं।
- Custom domains। domain खरीदने या जोड़ने के संदेश अब response के status और codes से चुने जाते हैं, न कि domain provider के अपने वाक्य आगे भेजे जाते हैं।
- Image generation। कार्ड हमारा संदेश दिखाता है; एजेंट को सेवा का विवरण मिलता है।
इसका उपयोग कैसे करें
- Publish बटन से हमेशा की तरह publish करें।
- अगर विफल हो, तो डायलॉग में एक-पंक्ति का संदेश पढ़ें।
- Fix with AI पर क्लिक करें। एजेंट build या ऐप के लॉग पढ़ता है, जो गलत है उसे ठीक करता है, और अगर ऐप में कुछ ठीक करने की ज़रूरत नहीं थी तो फिर publish करता है।
- या Try again पर क्लिक करें, उसी संस्करण को फिर publish करने के लिए। "कुछ देर के लिए व्यस्त" और "हमारी ओर की समस्या" के लिए यही सही है।
- अगर संदेश link name के बारे में है, तो फिर publish करने से पहले link name बदलें। किसी और त्रुटि के लिए नाम वही रखें।
सीमाएँ
- कुछ विफलताओं पर अलग बटन दिखते हैं: कब्ज़ा हुआ link name दूसरे नाम सुझाता है, और क्रेडिट खत्म होने पर क्रेडिट जोड़ने का रास्ता दिखता है।
- स्टैटिक साइट्स की प्रति-फ़ाइल सीमा साइट के प्रकार के अनुसार लगभग 25–30 MB है, और अधिकतम 20,000 फ़ाइलें। बड़ी फ़ाइलें storage में रखकर उनसे लिंक करना बेहतर है।
- इस बदलाव से पहले की विफल publishes में प्रकार नहीं है, इसलिए वे विशिष्ट कारण के बजाय एक सामान्य पंक्ति दिखाते हैं।
- अगर "हमारी ओर की समस्या" बार-बार आए, तो प्रोजेक्ट ID और link name के साथ support से संपर्क करें।
सभी संदेशों की पूरी सूची और हर एक पर क्या करना है, वह publish troubleshooting में है। अगर आप कोई ज़िद्दी ऐप हाथ से ठीक कर रहे हैं, तो AI से बनी ऐप को डिबग कैसे करें गाइड उसे कदम-दर-कदम समझाती है। और लाइव साइट का रीपब्लिश के दौरान क्या होता है, इसके लिए देखें: आपका published ऐप अब रीपब्लिश के दौरान भी चालू रहता है।