SYNC131: स्टोर सर्वर त्रुटि
इसका क्या अर्थ है
आपके स्टोर ने त्रुटि लौटाई, इसलिए यह क्रिया पूरी नहीं हुई।
स्टोर तक पहुँच तो हो गई, लेकिन उसका सर्वर अनुरोध संभालने में विफल रहा। यह POS के बजाय वेबसाइट की समस्या है, इसलिए केवल दोबारा प्रयास करने से मदद नहीं मिल सकती: साइट का त्रुटि लॉग जाँचें या होस्ट से जाँचने को कहें, फिर दोबारा प्रयास करें। इस डिवाइस पर कुछ भी नहीं खोया।
क्या करें
यह क्रिया फिर से आज़माएँ। WCPOS इसे स्वयं दोबारा नहीं आज़माता — जब आप तैयार हों तब पुनः प्रयास करें।
आपका डेटा
यह बदलाव इस डिवाइस पर सहेजा गया है लेकिन आपके स्टोर तक नहीं पहुँचा है। यदि यह बना रहे, तो डायग्नोस्टिक्स एक्सपोर्ट करें और WCPOS सपोर्ट से संपर्क करें।
समस्या निवारण
- लॉग प्रविष्टि विस्तृत करें और status, endpoint तथा serverCode नोट करें — ये बताते हैं कि विफल होते समय सर्वर क्या कर रहा था।
- साइट पर WooCommerce → स्थिति → लॉग्स खोलें और विफलता के समय के आसपास का सबसे नया fatal-errors लॉग जाँचें; 500-श्रेणी की प्रतिक्रिया लगभग हमेशा वहाँ PHP त्रुटि छोड़ती है।
- यदि विफलता साइट पर किसी प्लगइन, थीम या PHP अपडेट के बाद शुरू हुई हो, तो पहले उसी बदलाव पर संदेह करें और उसे वापस लें या बंद करें।
- यदि WooCommerce के लॉग में कुछ न दिखे, तो होस्टिंग प्रदाता से उसी समयावधि के लिए सर्वर का PHP त्रुटि लॉग माँगें।
- सर्वर-साइड कारण ठीक हो जाने के बाद, POS से दोबारा प्रयास करें — बदलाव अब भी इस डिवाइस पर सहेजा हुआ है।
कहाँ देखें
जब WCPOS इस त्रुटि को सहेज पाता है, तो वह उसी डिवाइस पर दर्ज होती है जिसने उसे उत्पन्न किया। स्टोर हेल्थ → लॉग्स खोलें (नेविगेशन ड्रॉअर में सबसे नीचे दिया गया हार्ट-पल्स आइकॉन), इस कोड से चिह्नित प्रविष्टि ढूँढें और उसे विस्तृत करें: विस्तृत पंक्ति में सरल भाषा में कारण और विफलता के समय दर्ज किया गया संदर्भ दिखाई देता है। स्टोर अनुरोध की स्थिति में उस संदर्भ में सर्वर का अपना त्रुटि कोड (serverCode), HTTP status या endpoint शामिल हो सकता है; कौन-से फ़ील्ड दिखेंगे यह इस बात पर निर्भर करता है कि विफलता कहाँ हुई। समस्या की रिपोर्ट करते समय स्क्रीनशॉट के बजाय लॉग्स स्क्रीन के ऊपर दिए गए डिबग जानकारी कॉपी करें (फ़ोन और टैबलेट पर डिबग जानकारी साझा करें) का उपयोग करें: यह ऐप संस्करण, कनेक्शन स्थिति और सबसे हालिया त्रुटियों को एक साथ इकट्ठा कर देता है। लॉग्स अधिकतम 30 दिनों तक रखे जाते हैं, इसलिए समस्या ताज़ा रहते ही उन्हें इकट्ठा कर लें। साथ ही, POS द्वारा अपनी लॉग प्रविष्टि लिख पाने से पहले ब्राउज़र कंसोल में दिखी किसी भी त्रुटि को भी कॉपी करें।
ऐप के भीतर मौजूद लॉग के अलावा, यह विफलता इन जगहों पर भी सुराग छोड़ सकती है:
- नेटवर्क इंस्पेक्टर (वेब और डेस्कटॉप): डेवलपर टूल्स खोलें — ब्राउज़र में F12 दबाएँ, या डेस्कटॉप ऐप के मेनू में उन्नत → डेवलपर टूल्स टॉगल करें चुनें — और नेटवर्क टैब चुनें। पहले इस पेज का पुनः प्रयास संबंधी मार्गदर्शन अपनाएँ; क्रिया को केवल तभी दोहराएँ जब वे चरण कहें कि ऐसा करना सुरक्षित है। विफल अनुरोध में HTTP स्थिति और कच्ची प्रतिक्रिया बॉडी दिखती है, जिसमें वे त्रुटि पेज भी शामिल हैं जो कभी POS लॉग तक नहीं पहुँचते।
- सर्वर-साइड POS लॉग्स: WP Admin में POS → सेटिंग्स → टूल्स → लॉग्स खोलें। यह पेज सर्वर पर ही उत्पन्न हुई POS-संबंधी चेतावनियाँ और त्रुटियाँ दर्ज करता है, जो ऐप के भीतर कभी दिखाई नहीं दे सकतीं। मेनू पर लाल बैज का अर्थ है कि सर्वर-साइड त्रुटियाँ अपठित हैं।
- WooCommerce → स्थिति → लॉग्स: WordPress साइट पर PHP क्रैश के लिए सबसे नया
fatal-errors-*.logजाँचें, साथ ही विफलता में शामिल किसी भी प्लगइन के नाम वाला लॉग स्रोत भी। स्टोर से आने वाली 500-श्रेणी की त्रुटि का कारण लगभग हमेशा यहीं दर्ज होता है। - साइट का PHP त्रुटि लॉग: यदि WooCommerce का लॉग पेज विफलता के समय के लिए कुछ न दिखाए, तो होस्टिंग प्रदाता से PHP त्रुटि लॉग माँगें — कुछ फ़ैटल त्रुटियाँ केवल सर्वर स्तर पर ही दर्ज होती हैं।
विवरण
- कोड:
SYNC131(STORE_SERVER_ERROR) - गंभीरता: error
- इसमें जोड़ा गया: WCPOS 1.10.0