Publish کی خرابیاں اب سادہ الفاظ میں بتائی جاتی ہیں

جب Mythex پر publish ناکام ہوتا ہے تو ڈائیلاگ اب ایک سادہ جملے میں بتاتا ہے کہ کیا ہوا: build ناکام ہوا، آپ کی app شروع ہونے کے بعد رک گئی، آپ کی app شروع ہی نہیں ہوئی، فائل بہت بڑی ہے، یا ہماری طرف کچھ خراب ہوا۔ اور یہ Fix with AI اور Try again پیش کرتا ہے۔ build اور آپ کی app سے آنے والی خام output اب بھی ایجنٹ تک پہنچتی ہے، تاکہ Fix with AI اسے پڑھ کر پروجیکٹ ٹھیک کر سکے، مگر آپ کو خود اسے پڑھنے کی ضرورت نہیں۔

کیا بدلا ہے

ایک جملہ جس پر آپ عمل کر سکیں

ہر ناکام publish کی ایک قسم ہے، جو اسی لمحے طے ہوتی ہے جب وہ ناکام ہوتا ہے، ان حقائق سے جو ہمارے پاس وہیں ہوتے ہیں: کون سا قدم ناکام ہوا، کیا app کی مشین نے crashes رپورٹ کیے، کیا وہ کبھی کنکشن قبول کرنے لگی۔ بعد میں خرابی کا متن پڑھ کر نہیں۔ ہر قسم کا اپنا پیغام ہے:

ہر ناکامی پر Fix with AI

ہر ناکامی پر Fix with AI اور Try again دکھتے ہیں۔ جب آپ Fix with AI استعمال کرتے ہیں تو ایجنٹ کو ناکامی کی قسم اور build یا app کی پوری output نجی طور پر، اپنے context میں ملتی ہے۔ اگر آپ کی app میں کچھ غلط ہو تو وہ اسے ٹھیک کرتا ہے۔ اگر کچھ غلط نہ ہو، جیسے ایک مصروف لمحہ یا ہماری طرف کا مسئلہ، تو وہ بس دوبارہ publish کر سکتا ہے۔ آپ کو یہ نہیں سوچنا پڑتا کہ کون سی قسم کی ناکامی تھی۔

live ہونے کے بعد کے مسائل

ایک publish کامیاب ہو سکتی ہے اور app چند منٹ بعد ناکام ہو سکتی ہے۔ Mythex publish شدہ apps کی باقاعدگی سے جانچ کرتا ہے۔ اگر کوئی live app بار بار crash ہو، یا چلتی رہے مگر کنکشن قبول کرنا بند کر دے، تو publish ناکام نشان زد ہوتا ہے، آپ کو ای میل ملتی ہے، اور پروجیکٹ میں وہ پیغام Fix with AI کے ساتھ دکھتا ہے۔ app نے جو کچھ پرنٹ کیا وہ ایجنٹ کے پڑھنے کے لیے محفوظ ہوتا ہے۔

upload سے پہلے سائز کی حدیں چیک

static sites کے لیے، کسی بھی چیز کے upload ہونے سے پہلے ہر فائل کا سائز اور فائلوں کی کل تعداد چیک ہوتی ہے۔ اگر کچھ حد سے بڑا ہو تو آپ کو ایک پیغام ملتا ہے جس میں ہر بڑی فائل درج ہوتی ہے، بجائے اس کے کہ کام کے بیچ میں ناکامی ہو۔

ہم نے یہ کیوں بنایا

ناکام publish پہلے وہ دکھاتا تھا جو publishing کے پیچھے کے ٹولز نے چھاپا ہو۔ ستمبر کے آخر کے ایک ہفتے میں، زیادہ تر ناکامیاں ایسا متن دکھاتی تھیں جو بلڈرز کے لیے نہیں بلکہ ہمارے لیے تھا: billing contacts، اندرونی ورژن نمبر، registry کے راستے، storage کی خرابیاں۔ Fix with AI پھر وہی متن چیٹ میں چسپاں کر دیتا۔ لوگوں سے کہا جا رہا تھا کہ ہمارے infrastructure کو ٹھیک کریں۔

ان میں سے کچھ بالکل غلط بھی تھا۔ ایک app جو اپنے port پر نہیں سنتی تھی، اسے “ہماری طرف کا مسئلہ” بتایا جاتا تھا، حالانکہ حل app کے اندر تھا۔ سائز کی حد سے بڑی static فائل کو بھی یہی کہا جاتا تھا، حالانکہ دوبارہ publish کرنا کبھی کام نہیں کر سکتا تھا۔

اور Mythex کا ہر وہ حصہ جو کسی ناکامی پر ردِعمل دیتا تھا، جیسے ڈائیلاگ، notifications، Fix with AI، اور ہمارے اپنے alerts، یہ اندازہ لگاتا تھا کہ کیا ہوا خرابی کے متن میں الفاظ ملا کر۔ جب بھی الفاظ بدلتے، یہ ٹوٹ جاتا۔ اب قسم اسی جگہ ریکارڈ ہوتی ہے جہاں ناکامی ہوتی ہے، اور باقی سب قسم پڑھتے ہیں۔

یہی اصول ہم نے دوسری خرابیوں پر بھی لاگو کیا:

• چیٹ۔ اگر جواب stream ہوتے ہوئے کنکشن ٹوٹ جائے تو آپ کو براؤزر کا “Load failed” یا “Failed to fetch” نہیں، بلکہ ہمارا جملہ دکھتا ہے۔
• Custom domains۔ domain خریدنے یا جوڑنے کے پیغامات اب جواب کے status اور codes سے چنے جاتے ہیں، بجائے اس کے کہ domain فراہم کنندہ کے اپنے جملے آگے بڑھائے جائیں۔
• Image generation۔ card ہمارا پیغام دکھاتا ہے؛ ایجنٹ کو سروس کی تفصیل ملتی ہے۔

استعمال کا طریقہ

1. معمول کے مطابق Publish بٹن سے publish کریں۔
2. اگر ناکام ہو تو ڈائیلاگ میں ایک سطر کا پیغام پڑھیں۔
3. Fix with AI پر کلک کریں۔ ایجنٹ build کی output یا آپ کی app کے logs پڑھتا ہے، جو غلط ہو اسے ٹھیک کرتا ہے، اور اگر app میں کچھ ٹھیک کرنے کی ضرورت نہ ہو تو دوبارہ publish کرتا ہے۔
4. یا Try again پر کلک کریں تاکہ وہی ورژن دوبارہ publish ہو۔ “busy for a moment” اور “a problem on our side” کے لیے یہی درست انتخاب ہے۔
5. اگر پیغام لنک کے نام کے بارے میں ہے تو دوبارہ publish کرنے سے پہلے لنک کا نام بدلیں۔ کسی اور خرابی پر وہی نام رکھیں۔

حدود

• کچھ ناکامیاں مختلف بٹن دکھاتی ہیں: لیے ہوئے لنک نام کے لیے دوسرے نام تجویز ہوتے ہیں، اور کریڈٹ ختم ہونے پر کریڈٹ شامل کرنے کا راستہ دیا جاتا ہے۔
• static sites کی فی فائل حد تقریباً 25 تا 30 MB ہے، سائٹ کی قسم کے مطابق، اور زیادہ سے زیادہ 20,000 فائلیں۔ بڑی فائلیں storage میں رکھ کر ان کا لنک دینا بہتر ہے۔
• اس تبدیلی سے پہلے کی ناکام publishes کی کوئی قسم نہیں ہوتی، اس لیے وہ کوئی مخصوص وجہ کے بجائے ایک عام سطر دکھاتی ہیں۔
• اگر “a problem on our side” بار بار آئے تو پروجیکٹ ID اور لنک نام کے ساتھ سپورٹ سے رابطہ کریں۔

ہر پیغام کی مکمل فہرست اور ہر ایک پر کیا کرنا ہے، publish troubleshooting میں ہے۔ اگر آپ کسی ضدی app کو خود ٹھیک کر رہے ہیں تو ہماری گائیڈ AI سے بنی app کی خرابی کیسے دور کریں مرحلہ وار بتاتی ہے۔ اور دوبارہ publish کرتے وقت لائیو سائٹ کا کیا ہوتا ہے، اس کے لیے دیکھیں آپ کی publish شدہ app اب دوبارہ publish کرتے ہوئے بھی چلتی رہتی ہے۔