← Semua project

Sistem Manajemen Audit

Smart Audit

Proses audit: auditor mengerjakan tugas inspeksi, mencatat temuan, dan memvalidasi data sebelum masuk ke laporan.

Role & lingkup
Fullstack Developer
Stack teknologi
Vue.js · Quasar · Golang
Alur pemulihan Smart Audit ilustratif: inspeksi tersimpan, assignment gagal, kedua record diambil ulang, dan hanya langkah gagal diulang dengan lock_version terbaru. Status fiktif; bukan screenshot produksi.
Ilustrasi konseptual dengan data atau status fiktif. Bukan screenshot produksi.

Konteks & masalah

Smart Audit mengirim inspeksi dan assignment-nya sebagai dua request terpisah. Ketika request kedua gagal — koneksi terputus, atau ditolak validasi API — request pertama sudah tersimpan. Recordnya tertinggal separuh jadi: inspeksi tanpa assignment, dengan status yang tidak lagi menggambarkan keadaan sebenarnya.

Pengguna & tim

Auditor yang mengirim data dari perangkat mobile, sering kali dengan koneksi yang tidak stabil. Kegagalan di tengah submission harus sesedikit mungkin mengorbankan pekerjaan mereka.

Kontribusi pribadi

  • Mempertahankan state formulir di sisi lokal dan menulis penanda pemulihan ketika suatu langkah submission gagal.
  • Mengambil ulang record inspeksi dan assignment untuk menentukan langkah mana yang sudah berhasil.
  • Hanya mengulang langkah yang gagal, menggunakan lock_version terbaru.

Arsitektur & keputusan

Vue.js dan Quasar di frontend, Golang di backend.

Pemulihan membaca state dari server, bukan mempercayai state di klien. Kedua record diambil ulang dan dicocokkan sebelum apa pun diulang, sehingga retry berpijak pada apa yang benar-benar tersimpan, bukan pada apa yang diyakini sudah terkirim oleh perangkat.

Fitur utama

  • Progres formulir bertahan setelah satu langkah submission gagal.
  • Record inspeksi dan assignment dicocokkan sebelum retry dijalankan.
  • Hanya langkah yang gagal yang diulang, terhadap versi record saat ini.

Tantangan & solusi

Mengulang request adalah respons yang paling wajar terhadap langkah yang gagal, sekaligus yang paling berisiko. Di antara kegagalan dan retry, record itu bisa saja sudah berubah — disunting orang lain, atau berubah karena request sebelumnya baru tiba terlambat. Retry yang buta akan menimpa data yang lebih baru.

Mengirim lock_version terbaru bersama retry menutup celah itu: penulisan ditolak jika record berubah setelah terakhir dibaca. Digabung dengan pengambilan ulang kedua record, retry hanya akan menyelesaikan langkah yang memang masih kurang.

Hasil

Hanya langkah yang gagal yang diulang, sehingga penyimpanan sebagian tidak lagi memaksa pengguna mengirim ulang seluruh formulir.