Publish चे error आता साध्या शब्दांत काय झाले ते सांगते
Mythex वर publish अयशस्वी झाल्यावर डायलॉग आता एका साध्या वाक्यात सांगतो की काय घडले — build अयशस्वी झाला, तुमचे अ‍ॅप सुरू झाल्यानंतर लगेच थांबले, अ‍ॅप सुरूच झाले नाही, फाईल खूप मोठी आहे, किंवा आमच्या बाजूने काहीतरी चुकले — आणि Fix with AI व Try again देतो. Build आणि तुमच्या अ‍ॅपचे कच्चे आउटपुट तरीही एजंटपर्यंत पोहोचते, त्यामुळे Fix with AI ते वाचून प्रोजेक्ट दुरुस्त करू शकतो, पण तुम्हाला ते स्वतः वाचावे लागत नाही.
काय बदलले
एक वाक्य ज्यावर तुम्ही कृती करू शकता
प्रत्येक अयशस्वी publish आता एक प्रकार घेऊन येतो, ते अपयश घडते त्याच क्षणी ठरलेला — त्या वेळी आमच्याकडे असलेल्या तथ्यांवरून: कोणती पायरी अयशस्वी झाली, अ‍ॅपच्या मशीनने crashes नोंदवले का, आणि ते कधी connections स्वीकारू लागले का — त्यानंतर error मजकूर वाचून नव्हे. प्रत्येक प्रकाराचा स्वतःचा संदेश आहे:
| तुम्हाला काय दिसते | त्याचा अर्थ |
|---|---|
| "The build failed." | तुमच्या प्रोजेक्टची build command किंवा Dockerfile build झाले नाही. |
| "Your app stopped right after it started." | ते publish झाले, मग बाहेर पडले किंवा सतत restart होत राहिले. |
| "Your app didn't start after publishing." | ते publish झाले, पण कधीही connections स्वीकारू लागले नाही. |
| "This file is too big" / खूप जास्त फाईल्स | Static साइट प्रति-फाईल आकार किंवा फाईल-संख्या मर्यादेपलीकडे आहे. संदेशात फाईल्सची यादी आहे. |
| "This link name can't be used for publishing." | लिंकचे नाव बदला आणि पुन्हा 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 published अ‍ॅप्स नियमितपणे तपासतो. एखादे live अ‍ॅप सतत crash होत असेल, किंवा चालत असूनही connections स्वीकारत नसेल, तर publish failed म्हणून चिन्हांकित होते, तुम्हाला ईमेल येतो, आणि प्रोजेक्टवर संदेश Fix with AI सह दिसतो. अ‍ॅपने जे छापले ते एजंटने वाचण्यासाठी जतन केले जाते.
Upload पूर्वी आकाराच्या मर्यादा तपासणे
Static साइट्ससाठी प्रत्येक फाईलचा आकार आणि एकूण फाईल-संख्या काहीही upload होण्यापूर्वी तपासली जाते. काहीतरी मर्यादेबाहेर असेल तर एक संदेश येतो, ज्यात खूप मोठ्या प्रत्येक फाईलची यादी असते, मध्येच एका अपयशाऐवजी.
हे का बनवले
अयशस्वी publish पूर्वी publishing मधील साधनांनी छापलेले काहीही दाखवत असे. सप्टेंबरच्या शेवटी एका आठवड्यात बहुतेक अपयशांमध्ये builder चा मजकूर दिसत होता जो आमच्या हाताळण्याचा होता, त्यांचा नव्हता: billing contacts, अंतर्गत आवृत्ती क्रमांक, registry paths, storage errors. Fix with AI तोच मजकूर चॅटमध्ये पुन्हा चिकटवत असे. लोकांना आमच्या पायाभूत सुविधांचे debugging करायला सांगितले जात होते.
त्यातील काही फक्त चुकीचे होते. ज्या अ‍ॅपने आपल्या port वर ऐकलेच नव्हते त्याला "आमच्या बाजूने समस्या" म्हटले गेले, जेव्हा दुरुस्ती अ‍ॅपमध्ये होती. आकार मर्यादेपलीकडची static फाईलही तशीच नोंदवली गेली — आणि पुन्हा publish केल्याने कधीच काम होऊ शकत नव्हते.
आणि Mythex चा प्रत्येक भाग जो अपयशाला प्रतिक्रिया देत होता — डायलॉग, सूचना, Fix with AI, आमचे स्वतःचे alerts — error मजकुरातील शब्द जुळवून काय झाले ते ठरवत असे. शब्द बदलले की ते तुटत असे. आता प्रकार अपयश घडतेच तिथे नोंदला जातो, आणि इतर सर्व गोष्टी त्या प्रकाराचे वाचन करतात.
तिथे असताना आम्ही इतर errors ना तोच नियम लावला:
- Chat. उत्तर streaming होत असताना कनेक्शन तुटले तर ब्राउझरचे "Load failed" किंवा "Failed to fetch" ऐवजी आता तुम्हाला आमचे वाक्य दिसते.
- Custom domains. Domain खरेदी किंवा जोडण्याबद्दलचे संदेश आता उत्तराच्या status आणि codes वरून निवडले जातात, domain provider चे स्वतःचे वाक्य पुढे पाठवण्याऐवजी.
- Image generation. Card आमचा संदेश दाखवतो; एजंटला सेवेचा तपशील मिळतो.
कसे वापरायचे
- Publish बटणावरून नेहमीप्रमाणे publish करा.
- अपयश आले तर डायलॉगमधील एका ओळीचा संदेश वाचा.
- Fix with AI क्लिक करा. एजंट build आउटपुट किंवा तुमच्या अ‍ॅपचे लॉग वाचतो, जे चुकले ते दुरुस्त करतो, आणि अ‍ॅपमध्ये काही दुरुस्त करण्याची गरज नसेल तर पुन्हा publish करतो.
- किंवा Try again क्लिक करा, तीच आवृत्ती पुन्हा publish करण्यासाठी — "busy for a moment" आणि "a problem on our side" साठी योग्य पर्याय.
- संदेश लिंकच्या नावाबद्दल असेल तर पुन्हा publish करण्यापूर्वी लिंकचे नाव बदला. इतर कोणत्याही errorसाठी तेच नाव ठेवा.
मर्यादा
- काही अपयशांवर वेगळी बटणे दिसतात: लिंकचे नाव आधीच घेतले असेल तर पर्यायी नावे सुचवली जातात, आणि क्रेडिट्स संपल्यावर क्रेडिट्स जोडण्याचा पर्याय दिसतो.
- Static साइट्सवर प्रति-फाईल मर्यादा साइटच्या प्रकारानुसार सुमारे 25–30 MB आहे, आणि 20,000 फाईल्सपर्यंत. मोठ्या फाईल्स storage मध्ये ठेवून त्यांना लिंक करणे चांगले.
- या बदलापूर्वीच्या अयशस्वी publishes ला प्रकार नाही, त्यामुळे त्यांना विशिष्ट कारणाऐवजी एक तटस्थ ओळ दिसते.
- "आमच्या बाजूची समस्या" वारंवार होत राहिली तर प्रोजेक्ट ID आणि लिंकच्या नावासह support शी संपर्क करा.
सर्व संदेश आणि प्रत्येकावर काय करायचे त्याची संपूर्ण यादी publish troubleshooting मध्ये आहे. हाताने एखादे हट्टी अ‍ॅप दुरुस्त करत असाल तर AI ने बनवलेले अ‍ॅप कसे debug करायचे हे guide पायरीपायरीने सांगते. आणि republish करताना live साइटचे काय होते यासाठी, तुमचे published अ‍ॅप आता republish करताना चालू राहते पहा.