आपका स्वचालन इतिहास एक सफल रन और एक आउटपुट बंडल दिखाता है। फेसबुक दो पोस्ट दिखाता है.
यह साक्ष्य कुछ सरल व्याख्याओं को खारिज करता है, लेकिन यह साबित नहीं करता है कि किस प्रणाली ने लेखन की नकल की है। स्वचालन दोबारा न चलाएँ. दोनों provider originalों को सुरक्षित रखें और फेसबुक तक पहुंचने वाले प्रत्येक लेख के लिए एक साक्ष्य पंक्ति बनाएं।
यह चेकलिस्ट उस विशिष्ट मामले को कवर करती है जहां एयरटेबल, मेक, एन8एन, या कस्टम वर्कफ़्लो एक बार चलता हुआ दिखाई देता है जबकि फेसबुक पेज को डुप्लिकेट पोस्ट प्राप्त होते हैं।
संक्षिप्त उत्तर
परिदृश्य बदलने से पहले, रिकॉर्ड करें:
- स्वचालन निष्पादन आईडी और सटीक प्रारंभ/समाप्ति समय
- प्रत्येक इनपुट बंडल या स्रोत-रिकॉर्ड आईडी
- पुनः प्रयास, अपूर्ण-निष्पादन, और टाइमआउट इतिहास
- हर फेसबुक पोस्ट की आईडी और पर्मलिंक
- प्रत्येक पोस्ट का सार्वजनिक टाइमस्टैम्प और प्रस्तुत सामग्री
यदि दो फेसबुक पोस्ट में अलग-अलग प्रदाता आईडी हैं, तो दो प्रदाता-पक्ष निर्मित थे, भले ही स्वचालन यूआई कार्य को एक रन के रूप में सारांशित करता हो। शेष प्रश्न यह है कि दूसरा निर्माण कहाँ से उत्पन्न हुआ: एक अन्य ट्रिगर, एक स्वचालित पुनः प्रयास, एक टाइमआउट पुनर्प्राप्ति, एक प्रदाता-पक्ष डुप्लिकेट, या एक ही स्रोत रिकॉर्ड का उपयोग करने वाला एक अलग क्लाइंट।
जब तक साक्ष्य उन रास्तों को अलग न कर दे तब तक कारण को लेबल न करें।
1. पहले दोनों सार्वजनिक मूल प्रतियों को सुरक्षित रखें
किसी एक को हटाने या संपादित करने से पहले दोनों फेसबुक पोस्ट खोलें। प्रत्येक पोस्ट के लिए, कैप्चर करें:
- पृष्ठ पहचान
- प्रदाता पोस्ट आईडी
- स्थायी लिंक
- प्रकाशित टाइमस्टैम्प
- सटीक कैप्शन और मीडिया
- कोई भी दृश्यमान लेखक या प्रकाशन विशेषता
टेक्स्ट और मीडिया फ़िंगरप्रिंट की तुलना करें. दो समान कैप्शन यह साबित नहीं करते कि वही अनुरोध दोबारा चलाया गया था; दो स्वतंत्र ग्राहक एक ही स्रोत रिकॉर्ड भेज सकते हैं। दो अलग-अलग प्रदाता आईडी साबित करती हैं कि प्रदाता ने दो सृजन स्वीकार किए हैं।
यदि केवल एक पर्मलिंक उपलब्ध है और दूसरी पोस्ट अभी भी दिखाई दे रही है, तो जांच करते समय एक स्क्रीनशॉट और सार्वजनिक टाइमस्टैम्प सुरक्षित रखें। गुम आईडी को unknown के रूप में चिह्नित करें।
2. एक प्रदाता लेखन से चलने वाले परिदृश्य को अलग करें
ग्रीन ऑटोमेशन रन का मतलब उस प्लेटफ़ॉर्म के नियमों के तहत पूरा किया गया ऑर्केस्ट्रेशन है। इसका मतलब यह नहीं है कि कोई बाहरी लेखन हुआ है।
दस्तावेज़ बनाएं कि कनेक्शन, दर-सीमा और टाइमआउट विफलताओं को अपूर्ण निष्पादन और घातीय बैकऑफ़ के माध्यम से पुनः प्रयास किया जा सके। इसके दस्तावेज़ में यह भी नोट किया गया है कि गैर-लेन-देन वाले बाहरी ऐप्स में कार्रवाइयों को वापस नहीं लिया जा सकता है। इसलिए प्रदाता का निर्माण तब भी सफल हो सकता है जब बाद वाला ग्राहक समय सीमा समाप्त कर देता है या प्रतिक्रिया खो देता है।
इन्हें अलग से जांचें:
| परत | साक्ष्य एकत्रित करना | यह क्या साबित कर सकता है |
|---|---|---|
| ट्रिगर | शेड्यूल/वेबहुक समय और ट्रिगर आईडी | कितने रन शुरू हुए |
| स्रोत | एयरटेबल रिकॉर्ड आईडी और इनपुट बंडल गिनती | प्रवाह में कितने रिकॉर्ड दर्ज हुए |
| मॉड्यूल बनाएं | मॉड्यूल संचालन, प्रारंभ/समाप्ति समय, कच्चा आउटपुट | कितने प्रदाता प्लेटफ़ॉर्म पर कॉल रिकॉर्ड करते हैं |
| पुनःप्रयास प्रणाली | अपूर्ण निष्पादन, स्वचालित पुनः प्रयास, बैकऑफ़ इतिहास | क्या कोई विफल या अस्पष्ट कॉल दोबारा चली |
| फेसबुक | प्रत्येक पोस्ट आईडी और पर्मलिंक | कितने सार्वजनिक प्रदाता ऑब्जेक्ट मौजूद हैं |
इन पाँच पंक्तियों को "रन सफल हुआ" में संक्षिप्त न करें।
3. छिपे हुए दूसरे ट्रिगर्स की जाँच करें
फेसबुक को दोष देने से पहले, उन कारणों को ख़त्म करें जिन्हें आप नियंत्रित कर सकते हैं:
- उसी पेज का उपयोग करके एक अन्य शेड्यूल किया गया परिदृश्य
- एक त्वरित वेबहुक और एक घंटे की खोज
- दूसरा कार्यक्षेत्र, वातावरण, या पुराना परिदृश्य
- समान सामग्री वाले दो स्रोत रिकॉर्ड
- पेज या बिजनेस सुइट से बनाई गई एक मैन्युअल पोस्ट
- एक मतदान विंडो जो किसी रिकॉर्ड का स्थिति अद्यतन दिखाई देने से पहले उसे फिर से चुनती है
केवल टाइमस्टैम्प ही नहीं, बल्कि स्थिर पहचानकर्ताओं का भी उपयोग करें। स्वचालन परिदृश्य आईडी, स्रोत-रिकॉर्ड आईडी, सामग्री फ़िंगरप्रिंट और गंतव्य पृष्ठ आईडी को एक ही पंक्ति में रिकॉर्ड करें।
यदि दो वर्कफ़्लो एक स्रोत तालिका साझा करते हैं, तो प्रदाता के निर्माण से पहले एक गंतव्य-विशिष्ट दावा या लॉक जोड़ें। केवल समय बफ़र ही निष्क्रियता की गारंटी नहीं है।
4. धीमी प्रतिक्रिया को अस्पष्ट मानें
लंबे समय से चल रहा फेसबुक मॉड्यूल महत्वपूर्ण साक्ष्य है, लेकिन यह स्वयं कारण की पहचान नहीं करता है।
यदि प्रदाता ने पोस्ट स्वीकार कर ली है और ग्राहक ने प्रतिक्रिया प्राप्त करने से पहले समय समाप्त कर लिया है, तो एक स्वचालित पुनः प्रयास एक और पोस्ट बना सकता है जब तक कि एकीकरण पहले परिणाम को समेट नहीं लेता। यदि दो पोस्ट मौजूद होने पर मॉड्यूल एक प्रदाता आईडी लौटाता है, तो बेजोड़ पोस्ट आईडी को सुरक्षित रखें और पूछें कि इसे किस अभिनेता ने बनाया है।
सुरक्षित नियम है:
गंतव्य की जांच होने तक टाइमआउट या खोई हुई प्रतिक्रिया
unknownहै,failedनहीं।
जब कोई प्रदाता आईडी या मेल खाने वाली सार्वजनिक पोस्ट पहले से मौजूद हो तो उस गंतव्य के लिए स्वचालित पुनर्प्राप्ति रोकें।
5. दो-पोस्ट साक्ष्य बही बनाएं
प्रति प्रदाता ऑब्जेक्ट एक पंक्ति का उपयोग करें:
destination_page_id:
source_record_id:
automation_execution_id:
create_module_operation_id:
retry_or_incomplete_execution_id:
provider_post_id:
provider_permalink:
provider_timestamp:
content_fingerprint:
public_outcome:
observed_in_automation_output: yes | no | unknownदो फेसबुक पोस्ट के लिए, लेज़र में दो पंक्तियाँ होनी चाहिए, भले ही ऑटोमेशन प्लेटफ़ॉर्म एक रन को उजागर करता हो। बेजोड़ क्षेत्र बताते हैं कि जांच को कहां मजबूत सबूत की जरूरत है।
6. एक गंतव्य-स्कोप पुनर्प्राप्ति गेट जोड़ें
बनाने या पुनः प्रयास करने से पहले, उस पृष्ठ के लिए मौजूदा रिकॉर्ड की जाँच करें:
- क्या पहले से ही कोई प्रदाता पोस्ट आईडी है?
- क्या कोई संग्रहीत पर्मलिंक है?
- क्या सार्वजनिक पृष्ठ में अपेक्षित समय विंडो में मिलान सामग्री फ़िंगरप्रिंट मौजूद है?
- क्या अधूरा निष्पादन अभी भी क्रिएट मॉड्यूल को पुनः प्रयास करने के योग्य है?
जब परिणाम अस्पष्ट हो, तो आइटम को दोबारा बनाने के बजाय मैन्युअल समाधान पर ले जाएं। जब कोई मल्टी-चैनल बैच आंशिक रूप से सफल होता है, तो अपने स्वयं के प्रदाता स्थिति की जांच करने के बाद केवल अनसुलझे गंतव्य का पुनः प्रयास करें।
यह गेट इस बात की गारंटी नहीं देता है कि प्रत्येक प्रदाता एक निष्क्रियता कुंजी को उजागर करता है। यह आपके पुनर्प्राप्ति तर्क को लापता क्लाइंट पुष्टिकरण को इस बात का प्रमाण मानने से रोकता है कि कुछ भी नहीं बनाया गया था।
किसी अन्य नेटवर्क से वास्तविक आंशिक-सफलता की चेतावनी
एक अलग ANKK थ्रेड्स घटना में, एक शेड्यूल किया गया रूट प्रकाशित किया गया था और उत्तर चरण में प्रदाता-अनुपलब्ध परिणाम का सामना करना पड़ा। स्वचालित पुनर्प्राप्ति ने दो समान सार्वजनिक उत्तर दिए, भले ही ऑपरेटर ने कोई मैन्युअल पुनः प्रयास नहीं किया। उत्पाद जांच के लिए provider original और स्थिर सामग्री और जॉब आईडी को संरक्षित किया गया था।
वह थ्रेड्स घटना फेसबुक डुप्लिकेट का कारण साबित नहीं करती है। यह सामान्य विफलता सीमा को प्रदर्शित करता है: एक बार जब कोई खंड प्रदाता तक पहुंच जाता है, तो पुनर्प्राप्ति के लिए पूरे ऑपरेशन की अंधाधुंध पुनरावृत्ति के बजाय उस खंड पर प्रदाता के सामंजस्य की आवश्यकता होती है।
स्रोत और अगले चरण
- मूल मेक कम्युनिटी केस: एक बंडल, एक लौटाई गई आईडी, दो फेसबुक पोस्ट
- बनाएं: अपूर्ण निष्पादन का स्वचालित पुनः प्रयास
- बनाएँ: घातीय बैकऑफ़
- बनाएं: रोलबैक त्रुटि हैंडलर और गैर-लेन-देन संबंधी बाहरी क्रियाएं
मैं ANKK संचालित करता हूं। ANKK में अंतर्निहित AI लेखक शामिल नहीं है। यह लोगों द्वारा तैयार की गई सामग्री, बाहरी एआई टूल या स्क्रिप्ट को सामाजिक शेड्यूलिंग, चैनल-स्तरीय स्थिति और प्रदाता-मूल सत्यापन से जोड़ता है।