Meshy API Webhooks बनाम Polling: परिणाम कब तैयार होते हैं

Meshy API जनरेशन टास्क (Text to 3D, Image to 3D, Rigging, और अन्य) एसिंक्रोनस रूप से चलते हैं — आप एक टास्क सबमिट करते हैं और फिर परिणाम प्राप्त करने से पहले यह पता लगाना होता है कि वह कब पूरा हुआ। यह लेख टास्क लाइफ़साइकल और यह जानने के दो समर्थित तरीकों की व्याख्या करता है कि टास्क कब समाप्त हुआ: पोलिंग और वेबहुक — साथ ही सबसे आम "मॉडल प्राप्त करने में त्रुटियाँ" समस्या से कैसे बचें।

हर जनरेशन टास्क कुछ स्थितियों से गुज़रता है, जो टास्क ऑब्जेक्ट के status फ़ील्ड में लौटाई जाती हैं:

• PENDING — टास्क कतार में है लेकिन प्रोसेसिंग अभी शुरू नहीं हुई है।

• IN_PROGRESS — टास्क सक्रिय रूप से प्रोसेस हो रहा है। काम पूरा होने पर progress फ़ील्ड (0-100) बढ़ता है।

• SUCCEEDED — टास्क सफलतापूर्वक पूरा हुआ और progress 100 है। परिणाम URL (मॉडल फ़ाइलें, टेक्सचर, प्रीव्यू) अब रिस्पॉन्स में उपलब्ध हैं।

• FAILED — टास्क पूरा नहीं हो सका। विफल टास्क के लिए क्रेडिट स्वतः रिफंड हो जाते हैं।

• CANCELED — टास्क पूरा होने से पहले रद्द कर दिया गया था।

API के साथ इंटीग्रेशन करते समय सबसे महत्वपूर्ण नियम: जब तक टास्क की status SUCCEEDED न हो जाए, परिणाम URL प्राप्त करने या उपयोग करने की कभी कोशिश न करें। टास्क के अभी भी PENDING या IN_PROGRESS होते समय परिणाम पढ़ना "मॉडल प्राप्त करने में त्रुटियाँ" की रिपोर्ट का सबसे आम कारण है।

पोलिंग का मतलब है अपने टास्क ID के लिए "get task" एंडपॉइंट को बार-बार कॉल करना जब तक वह टर्मिनल स्थिति (SUCCEEDED, FAILED, या CANCELED) तक न पहुँच जाए। एक सरल पोलिंग लूप ऐसा दिखता है:

• जनरेशन रिक्वेस्ट सबमिट करें और लौटाई गई टास्क id सेव करें।

• संबंधित "retrieve task" एंडपॉइंट (उदाहरण के लिए, Text to 3D या Image to 3D task-by-id एंडपॉइंट) को अंतराल पर कॉल करें — कुछ सेकंड आम है।

• हर रिस्पॉन्स पर status फ़ील्ड जाँचें। जब तक यह PENDING या IN_PROGRESS है, पोलिंग जारी रखें।

• जैसे ही status SUCCEEDED (परिणाम URL पढ़ें), FAILED, या CANCELED हो जाए, पोलिंग रोक दें।

• अपने क्लाइंट में एक उचित टाइमआउट/अधिकतम-प्रयास गार्ड जोड़ें ताकि अटका हुआ टास्क हमेशा के लिए पोल न करे।

पोलिंग सरल है और स्क्रिप्ट, बैच जॉब और कम-वॉल्यूम इंटीग्रेशन के लिए अच्छी तरह काम करती है। हाई-वॉल्यूम या लेटेंसी-संवेदी इंटीग्रेशन के लिए, वेबहुक आमतौर पर बेहतर विकल्प होता है।

"क्या यह पूरा हो गया?" बार-बार पूछने के बजाय, आप Meshy से कह सकते हैं कि टास्क पूरा होते ही वह आपके सर्वर को सूचित करे। वेबहुक का उपयोग करने के लिए:

• एक वेबहुक (कॉलबैक) URL कॉन्फ़िगर करें जिसे Meshy एक्सेस कर सके — यह आमतौर पर खाता/API सेटिंग्स स्तर पर सेट किया जाता है या जनरेशन रिक्वेस्ट पर पैरामीटर के रूप में पास किया जाता है, एंडपॉइंट के आधार पर।

• सुनिश्चित करें कि आपका एंडपॉइंट HTTPS पर सार्वजनिक रूप से सुलभ हो और तेज़ी से प्रतिक्रिया दे (तुरंत 2xx स्थिति लौटाएँ, फिर पेलोड को एसिंक्रोनस रूप से प्रोसेस करें)।

• जब टास्क टर्मिनल स्थिति तक पहुँचता है, Meshy आपके एंडपॉइंट पर टास्क id और उसकी अंतिम status युक्त पेलोड भेजता है।

• प्राप्ति पर, केवल वेबहुक बॉडी पर भरोसा करने के बजाय API के माध्यम से id द्वारा पूर्ण टास्क विवरण देखें, ताकि सुनिश्चित हो कि आपके पास प्रामाणिक, अद्यतित परिणाम है।

वेबहुक अनावश्यक API कॉल को कम करते हैं और लगभग तुरंत सूचना देते हैं, लेकिन उन टास्क के लिए आपको अभी भी आवधिक पोलिंग फ़ॉलबैक रखना चाहिए जहाँ वेबहुक डिलीवरी छूट सकती है या देरी हो सकती है (जैसे आपकी ओर किसी अस्थायी नेटवर्क समस्या के कारण)।

चाहे आप पोलिंग या वेबहुक का उपयोग करें, आपका परिणाम-हैंडलिंग कोड आइडेम्पोटेंट होना चाहिए — साइड इफ़ेक्ट के बिना उसी टास्क के लिए एक से अधिक बार चलना सुरक्षित हो। यह महत्वपूर्ण है क्योंकि:

• उसी टास्क के लिए वेबहुक एक से अधिक बार डिलीवर हो सकता है (सेंडर साइड पर रिट्राई, नेटवर्क डुप्लीकेशन, आदि)।

• एक पोलिंग लूप और वेबहुक हैंडलर दोनों उसी पूर्ण टास्क को प्रोसेस करने की कोशिश कर सकते हैं यदि दोनों चल रहे हों।

आइडेम्पोटेंट बने रहने के लिए, अपनी प्रोसेसिंग लॉजिक को टास्क id पर आधारित करें — उदाहरण के लिए, दोबारा करने से पहले जाँचें कि क्या आपने उस id के लिए परिणाम पहले ही सेव/डाउनलोड कर लिए हैं, और "processed के रूप में चिह्नित करें" को अपने डेटाबेस में एक एटॉमिक स्टेप बनाएँ।

"status": "SUCCEEDED" और "progress": 100 वाला रिस्पॉन्स ही एकमात्र संकेत है जो गारंटी देता है कि परिणाम पेलोड (मॉडल URL, टेक्सचर, थंबनेल) पूर्ण और उपयोग के लिए सुरक्षित है। ठोस रूप से, अपने कोड में:

• result/मॉडल URL फ़ील्ड से कुछ भी पढ़ने से पहले status === "SUCCEEDED" सत्यापित करें।

• केवल progress पर भरोसा न करें — हमेशा status भी जाँचें, क्योंकि टास्क पूरी तरह फ़ाइनलाइज़ होने से पहले प्रोग्रेस कुछ समय के लिए उच्च मान दिखा सकता है।

• SUCCEEDED होते ही परिणाम फ़ाइलें तुरंत डाउनलोड करें — जेनरेट की गई एसेट केवल सीमित समय के लिए Meshy के सर्वर पर रखी जाती हैं, जिसके बाद URL रिज़ॉल्व नहीं होंगे।

अधिकांश "मैं अपना मॉडल प्राप्त नहीं कर पा रहा" रिपोर्ट इनमें से किसी एक कारण तक जाती हैं:

• बहुत जल्दी फ़ेच करना। status के SUCCEEDED होने से पहले परिणाम URL को कॉल करना, या मॉडल फ़ील्ड पढ़ना। यह निस्संदेह सबसे आम कारण है।

• समाप्त हो चुकी एसेट। SUCCEEDED के बाद डाउनलोड करने में बहुत अधिक देर करना — उस टास्क प्रकार की रिटेंशन अवधि बीत जाने के बाद परिणाम URL काम करना बंद कर देते हैं।

• पुरानी या गलत टास्क ID का उपयोग करना — उदाहरण के लिए, पिछले असंबंधित रिक्वेस्ट की ID का पुनः उपयोग करना।

• FAILED को अस्थायी स्थिति मानना और पुनः सबमिट करने के बजाय पहले से विफल टास्क को पोल करते रहना।

• आपके सर्वर और Meshy के बीच नेटवर्क/टाइमआउट समस्याएँ जिन्हें जनरेशन समस्या समझ लिया जाता है।

यदि कोई जनरेशन आपकी अपेक्षाओं पर खरा नहीं उतरता, या कोई रिक्वेस्ट पूरी तरह विफल हो जाती है, तो निम्नलिखित बातें ध्यान में रखें:

• Meshy API वर्तमान में किसी मौजूदा टास्क को उसी जगह रिट्राई करना समर्थित नहीं करता — फिर से कोशिश करने के लिए, एक नया जनरेशन रिक्वेस्ट सबमिट करें, जो सामान्य रूप से क्रेडिट का उपभोग करेगा।

• API को कॉल करते समय अस्थायी नेटवर्क विफलताओं (टाइमआउट, 5xx रिस्पॉन्स) के लिए, रिक्वेस्ट दोबारा सबमिट करने से पहले संक्षिप्त एक्सपोनेंशियल बैकऑफ़ उचित है।

• पोलिंग के लिए, अस्थायी नेटवर्क त्रुटियों पर "get task" कॉल को रिट्राई करें, लेकिन एक विफल पोल को जनरेशन विफलता न मानें — केवल सफल रिस्पॉन्स मिलने पर ही status फ़ील्ड पर भरोसा करें।

• यदि आपको जनरेशन के लिए बिल्ट-इन रिट्राई सुविधा चाहिए, तो एंटरप्राइज़ प्लान विकल्पों के बारे में Meshy की सेल्स टीम से संपर्क करें।

यह लगभग हमेशा इसलिए होता है क्योंकि कोड टास्क समाप्त होने से पहले ही परिणाम पढ़ने की कोशिश कर रहा है। मॉडल URL प्राप्त करने से पहले हमेशा पुष्टि करें कि status SUCCEEDED है (और progress 100 है)।

पोलिंग सेट करने में सरल है और कम-वॉल्यूम या वन-ऑफ़ स्क्रिप्ट के लिए ठीक है। वेबहुक कई समवर्ती टास्क वाले प्रोडक्शन इंटीग्रेशन के लिए बेहतर हैं, क्योंकि वे अनावश्यक दोहराए गए रिक्वेस्ट से बचाते हैं और टास्क पूरा होने पर तुरंत सूचित करते हैं।

इसे आइडेम्पोटेंट रूप से हैंडल करें — टास्क id की जाँच करें कि आपने वह पहले से प्रोसेस किया है या नहीं, और यदि पहले से हैंडल किया गया है तो पुनः प्रोसेसिंग छोड़ दें।

सीधे id द्वारा टास्क को पोल करने पर लौटें। यह भी पुष्टि करें कि आपका एंडपॉइंट HTTPS पर सार्वजनिक रूप से सुलभ है और तेज़ 2xx रिस्पॉन्स देता है, क्योंकि धीमे या असुलभ एंडपॉइंट डिलीवरी समस्याएँ पैदा कर सकते हैं।

अभी नहीं — आपको एक नया जनरेशन रिक्वेस्ट सबमिट करना होगा, जो सामान्य रूप से क्रेडिट का उपभोग करता है। यदि आपको बिल्ट-इन रिट्राई समर्थन चाहिए तो एंटरप्राइज़ विकल्पों के बारे में सेल्स से संपर्क करें।

परिणाम फ़ाइलें केवल टास्क पूरा होने के बाद सीमित समय के लिए Meshy के सर्वर पर रखी जाती हैं, इसलिए प्रतीक्षा करने के बजाय टास्क सफल होते ही आउटपुट को अपने स्टोरेज में डाउनलोड कर लें।

• API का उपयोग करके जनरेशन परिणाम से मॉडल प्राप्त करते समय मुझे लगातार त्रुटियाँ क्यों आती हैं?