SIMRS Sync — dari Sekali Jalan ke Resumable
❌ Alur LAMA
Satu lintasan penuh. Kalau gagal di tengah, semua progres hilang dan run berikutnya mulai dari awal.
Masalahnya
✅ Alur BARU
Kolom sync_states.cursor menyimpan checkpoint per chunk. Run berikutnya melanjutkan dari titik itu.
Perbandingan berdampingan
| Aspek | ❌ Lama | ✅ Baru |
|---|---|---|
| Kalau job timeout | Progres hilang total | Dilanjutkan dari chunk terakhir |
| Batch yang mati | Tertinggal running selamanya | Ditandai failed oleh run berikutnya |
| Status di UI | Bisa berbohong | Jujur |
| Backfill tabel besar | Praktis mustahil | Selesai bertahap lintas beberapa run |
| Timeout job | Default | Dinaikkan sampai 6 jam |
| Watermark | Maju hanya kalau selesai | Sama — tidak berubah |
| Kolom baru | — | sync_states.cursor |
- Watermark (
last_watermark): sampai kapan data sudah tersinkron. Hanya maju kalau seluruh lintasan selesai. - Cursor: sampai baris mana lintasan yang sedang berjalan sudah sampai. Dikosongkan begitu lintasan selesai.
Keduanya harus ada. Watermark saja tidak cukup — ia hanya maju di akhir. Cursor saja juga tidak cukup — ia tidak tahu data mana yang berubah sejak sinkronisasi terakhir.
Ilustrasi pemulihan
Perbaikan kompatibilitas PostgreSQL yang menyertai
Perubahan ini datang bersama serangkaian perbaikan agar data SIMRS (MySQL) bisa masuk ke PostgreSQL.
Semua ini adalah kelas masalah yang sama: SIMRS adalah MySQL longgar, CRM adalah PostgreSQL ketat. Data yang lolos di sisi sumber belum tentu diterima di sisi tujuan.
Perbaikan lain yang menyertai
| Perbaikan | Alasan |
|---|---|
| Timeout job dinaikkan ke 6 jam | Backfill besar butuh waktu; cursor jadi jaring pengamannya |
| Paginasi database standar di halaman Pasien | Penggabungan hasil API di memori menyebabkan OOM saat jumlah pasien besar |
simrs_patient_id ditampilkan sebagai kolom "No. RM" | Petugas mencari pasien dengan nomor rekam medis, bukan ID internal |
Yang TIDAK berubah
Bagian ini tetap sama antara alur lama dan baru:
Rollback pun ikut menyesuaikan: kalau batch yang di-rollback adalah batch terakhir entitas tersebut, cursor ikut dikosongkan bersama pemunduran watermark.