غیر معتبر ای میل ٹیسٹ کا ورژن مختصر ہے: ایک ایڈریس بنائیں، پانچ سیکنڈ سُوتے رہیں، پہلی پیغام پڑھیں، اور امید کریں کہ یہ اس رن سے متعلق ہے۔
قابل اعتماد ورژن ابھی بھی سادہ ہے، لیکن یہ ڈلیوری کو غیر متزامن سمجھتا ہے۔ یہ ایک منفرد ایڈریس بناتا ہے، آغاز کا وقت ریکارڈ کرتا ہے، ڈیڈ لائن کے اندر پولنگ کرتا ہے، مطلوبہ پیغام سے میچ کرتا ہے، پروڈکٹ ایکشن کی توثیق کرتا ہے، اور کسی ناکامی کی صورت میں کافی سیاق و سباق رپورٹ کرتا ہے۔
API کلید کو URL سے باہر رکھیں
GPTMail کلید کو X-API-Key ہیڈر میں بھیجیں۔ اسے ?api_key= کوئری پیرامیٹر میں نہ رکھیں۔ URLs عام طور پر براؤزر ہسٹری، ایکسیس لاگز، مانیٹرنگ سسٹمز اور ریفرر ڈیٹا میں محفوظ رہتی ہیں۔
X-API-Key: YOUR_API_KEYکلید کو اپنے CI سیکرٹ مینیجر میں محفوظ کریں اور لاگز میں ماسک کریں۔ عوامی روزانہ کی کلید دریافت کے لیے آسان ہے؛ کنٹرول شدہ خودکار سوئٹس کو ایسی کلید استعمال کرنی چاہیے جس کی کوٹا اور استعمال آپ ٹریک کر سکیں۔
موجودہ اینڈ پوائنٹس اور ردعمل کی مثالیں GPTMail API دستاویزات صفحہ پر برقرار رکھی جاتی ہیں۔
ہر رن کے لیے ایک ایڈریس
ہر خود مختار ٹیسٹ کے لیے نیا ایڈریس بنائیں۔ پوری ٹیسٹ سوئٹ کے ساتھ شیئر کردہ ان باکس سے درستگی کا اندازہ نہ لگائیں۔
ایڈریس، سینیریو آئی ڈی، ماحول اور ٹیسٹ کے آغاز کا وقت ریکارڈ کریں۔ یہ اقدار آپ کو پرانے پیغامات کو مسترد کرنے اور ٹکراؤ کی تشخیص کرنے میں مدد دیتی ہیں بغیر پیغام کے راز لاگ کیے۔
مقررہ سُونے کے بجائے ڈیڈ لائن کے خلاف پولنگ کریں
ای میل کی ڈلیوری کا وقت مختلف ہوتا ہے۔ مقررہ پانچ سیکنڈ کی سُونے تیز ڈلیوری پر بیکار اور سست ڈلیوری پر غیر مستحکم ہوتی ہے۔
محدود لوپ استعمال کریں:
deadline = now + 90 seconds
delay = 2 seconds
while now < deadline:
messages = list inbox
candidate = newest message matching sender, subject, and start time
if candidate exists:
read candidate and continue the product test
wait delay with a small random jitter
delay = min(delay * 1.5, 10 seconds)ڈیڈ لائن ٹیسٹ کے معاہدے کا حصہ ہے۔ پاس ورڈ ری سیٹ فلو کو بلک نیوز لیٹر پیش نظارہ سے مختلف حد کی ضرورت ہو سکتی ہے۔ حد کو واضح رکھیں تاکہ سست انحصار پورے CI جاب کو چپچپے طور پر بڑھائے نہ۔
درست میچ کریں
“ان باکس کا پہلا پیغام” مفید سلیکٹر نہیں ہے۔ متعدد سگنلز سے میچ کریں:
- وصول کنندہ اس ایڈریس کے برابر ہو جو اس رن کے لیے بنایا گیا ہو؛
- تخلیق کا وقت ٹرگر کے وقت سے بعد کا ہو؛
- بھیجنے والا متوقع سروس سے تعلق رکھتا ہو؛
- موضوع یا پیغام کی قسم فلو سے میچ کرتی ہو؛
- پیغام کی شناخت (ID) پہلے سے استعمال نہ ہوئی ہو۔
جب بھیجنے والا متعدد کوڈز جاری کر سکتا ہے، تو جدید ترین میچ ہونے والا پیغام منتخب کریں۔ اس کی ID ٹیسٹ کے آؤٹ پٹ میں محفوظ رکھیں تاکہ ری ٹرائیز اسے غلطی سے دوبارہ استعمال نہ کر سکیں۔
فہرست میچ کے بعد ہی پڑھیں
ان باکس کی فہرست بنانا سستا دریافت مرحلہ ہونا چاہیے۔ مکمل پیغام صرف منتخب امیدوار کے لیے لیں۔ اس سے غیر ضروری کام کم ہوتا ہے اور غیر متعلقہ پروموشنل میل کی پارسنگ سے بچا جاتا ہے۔
کاروباری نتیجہ کی توثیق کریں، صرف چھ ہندسوں کی سٹرنگ کی موجودگی نہیں۔ کوڈ جمع کروائیں یا متوقع لنک کھولیں، پھر اس بات کی تصدیق کریں کہ اکاؤنٹ صحیح حالت تک پہنچ گیا۔
ریٹ لیمٹس کو ایک سگنل کے طور پر ہینڈل کریں
اگر API کوٹا یا ریٹ-لمیٹ ردعمل دیتی ہے تو موجودہ کوشش کو روکیں اور ری سیٹ کی معلومات ظاہر کریں۔ جارحانہ ری ٹرائیز واضح صلاحیت کے سگنل کو شور میں بدل دیتی ہیں اور غیر متعلقہ ٹیسٹس کو تاخیر کا شکار بناتی ہیں۔
ٹیسٹ رنر پر ہم وقتیت کو محدود کریں، خاص طور پر جب سوئٹ ایک ساتھ متعدد ایڈریسز بناتا ہے۔ چھوٹا ورکَر پول سینکڑوں بیک وقت پولنگ لوپس کے مقابلے میں ڈیبگ کرنا آسان ہے۔
ناکامیوں کو چھپائے بغیر صفائی کریں
صفائی اس وقت چلنی چاہیے جب شواہد جمع ہو چکے ہوں۔ کامیابی پر پیغامات ہٹا دیں یا مختصر ریٹینشن کو انہیں خود سنبھالنے دیں۔ ناکامی کی صورت میں ایڈریس اور پیغام کی ID کو محفوظ CI آرٹیفیکٹس میں کافی وقت تک رکھیں تاکہ تحقیق ہو سکے، پھر انہیں حذف کریں۔
کبھی بھی ویریفیکیشن کوڈز، پرائیویٹ لنکس، یا مکمل HTML باڈیز کو عوامی بلڈ لاگز میں پرنٹ نہ کریں۔
ری ٹرائیز کو آئڈیمپوٹنٹ بنائیں
ٹیسٹ کو نئی ایڈریس کے ساتھ نئی رن کے طور پر دوبارہ چلائیں۔ یہ فرض نہ کریں کہ ایک ہی اکاؤنٹ اور ان باکس کے خلاف ایک ہی درخواست دہرانے سے صاف حالت سے شروع ہوتی ہے۔ بھیجنے والا پرانے کوڈز کو غیر معتبر کر سکتا ہے، دہرانے والی درخواستوں کو سست کر سکتا ہے، یا ڈپلیکٹ دعوت نامے مسترد کر سکتا ہے۔
اگر نیٹ ورک درخواست کا ٹائم آؤٹ ہو جائے تو “کوئی ردعمل موصول نہیں ہوا” اور “آپریشن نہیں ہوا” میں فرق کریں۔ تباہ کن ری ٹرائی جاری کرنے سے پہلے قابل مشاہدہ حالت چیک کریں۔
ناکامی کا نقطہ رپورٹ کریں
ایک مفید خودکار ناکامی مندرجہ ذیل مراحل میں سے ایک کی نشاندہی کرتی ہے:
- ایڈریس کی تخلیق ناکام ہوئی؛
- پروڈکٹ ایکشن ای میل کی قطار میں شامل ہونے سے پہلے ناکام ہوا؛
- ڈیڈ لائن سے پہلے کوئی میچ کرنے والا پیغام نہیں آیا؛
- پیغام آیا لیکن مواد میچ نہیں کرتا؛
- توثیقی ایکشن ناکام ہوا؛
- صفائی ناکام ہوئی۔
یہ درجہ بندی ایک عارضی “ای میل ٹیسٹ ناکام ہوا” کو ٹیم کے لیے قابلِ ذمہ داری کام میں بدل دیتی ہے۔
بڑے ٹیسٹ میٹرکس کے لیے، پڑھیں ایک حقیقی ای میل ٹیسٹ پلان۔ ڈلیوری کی تشخیص کے لیے، استعمال کریں توثیقی ای میل موصول نہیں ہو رہی: خراب قدم کی نشاندہی کریں۔