Agen AI Anda di Elevare Digital menjadi tidak aktif (idle) karena kebijakan row-level security (RLS) PostgreSQL yang baru ditambahkan menyaring semua baris pekerjaan, sehingga antrean tampak kosong. Kesalahan ini tidak disadari hingga pekerjaan menumpuk, memaksa tim untuk merancang ulang cara orkestrator mendeteksi antrean kosong.

Titik buta yang tersembunyi

ARIA, sistem AI otonom Elevare, melakukan polling pada tabel PostgreSQL untuk mencari pekerjaan yang tertunda. Kueri berhasil, mengembalikan nol baris, dan agen tersebut pun "tertidur". Kenyataannya, tabel tersebut penuh. Kebijakan RLS membatasi akses SELECT ke set pengguna tertentu. Orkestrator terhubung dengan service role yang tidak memiliki hak istimewa bypass, sehingga database secara diam-diam menghapus setiap baris dari set hasil. PostgreSQL memperlakukan pembacaan yang tersaring sama seperti tabel kosong, sehingga tidak ada kesalahan, peringatan, atau kode kegagalan yang muncul. Heartbeat yang normal dari agen yang sedang idle tidak memberikan petunjuk bahwa ada sesuatu yang salah.

Bagaimana RLS mengubah antrean penuh menjadi keheningan

RLS menambahkan predikat ke setiap baris selama SELECT. Jika predikat bernilai salah (false), baris tersebut akan hilang dari hasil. Klien hanya melihat baris yang memenuhi kebijakan; klien tidak pernah tahu bahwa ada baris yang disembunyikan. Bagi pekerja antrean (queue worker), set hasil yang kosong terlihat persis seperti antrean yang benar-benar kosong. Orkestrator berasumsi "tidak ada baris = tidak ada pekerjaan" dan masuk ke dalam idle loop-nya sementara pekerjaan menumpuk di balik layar.

Tim menemukan bahwa kebijakan yang dimaksudkan untuk membatasi pembacaan ke pengguna individu secara tidak sengaja turut membatasi service role itu sendiri. Karena peran tersebut tidak memiliki atribut khusus "bypass RLS", kebijakan tersebut diterapkan pada setiap kueri yang dikeluarkan oleh orkestrator. Ini mengilustrasikan trade-off klasik antara keamanan vs observabilitas: RLS melindungi data dari pengguna yang tidak berwenang, tetapi juga menghilangkan sinyal kegagalan yang berguna bagi komponen sistem yang bergantung pada visibilitas.

Pola canary-check

Untuk memutus ketergantungan pada hasil kosong yang sunyi, Elevare menambahkan pemeriksaan "canary". Alur barunya adalah:

  1. Kueri tabel pending-jobs.
  2. Jika baris dikembalikan, proses seperti sebelumnya.
  3. Jika hasilnya kosong, jalankan kueri kedua terhadap baris canary khusus yang harus selalu ada.
  4. Jika kueri canary mengembalikan baris yang diharapkan, antrean benar-benar kosong; catat idle heartbeat.
  5. Jika kueri canary juga tidak mengembalikan apa pun, agen tersebut mengalami "kebutaan"; segera berikan peringatan (alert).

Sekarang orkestrator membedakan tiga status:

  • Pekerjaan ditemukan – pemrosesan normal.
  • Tidak ada pekerjaan, canary OK – periode idle yang sebenarnya.
  • Tidak ada pekerjaan, canary gagal – blokade RLS tersembunyi, picu peringatan.

Tabel canary adalah satu baris tunggal yang tidak pernah berubah. Pengaturannya memakan waktu sekitar satu jam, tetapi ini menghilangkan seluruh kelas kegagalan yang sunyi.

Apa yang harus dilakukan tim

Jika Anda menjalankan queue worker terhadap PostgreSQL atau layanan terkelola (hosted service) yang dibangun di atasnya (seperti Supabase), ikuti langkah-langkah berikut:

  • Gunakan kredensial service-role dengan bendera (flag) "bypass RLS". Ini memungkinkan komponen sistem melihat semua baris tanpa mempedulikan kebijakan tingkat pengguna.
  • Audit kebijakan RLS untuk memastikan tidak ada izin bypass yang hilang bagi service role. Kebijakan yang tampak benar bagi pengguna akhir mungkin secara tidak sengaja menjebak layanan internal.
  • Tambahkan tabel canary (atau baris setara yang selalu ada) dan masukkan pemeriksaan canary ke dalam logika idle pekerja. Kueri tambahan ini murah dan menyediakan jaring pengaman yang jelas.

Trade-off

RLS tetap menjadi alat yang ampuh untuk menegakkan akses data yang terperinci (fine-grained). Ini mencegah kebocoran data yang tidak disengaja dan mendukung arsitektur multi-tenant tanpa harus menyebarkan filter tingkat aplikasi ke seluruh basis kode. Sisi negatifnya adalah RLS dapat menyembunyikan kegagalan dari komponen yang mengharapkan sinyal sederhana "tidak ada baris" berarti "tidak ada yang perlu dilakukan". Pola canary tidak memperlemah RLS; pola ini menambahkan langkah verifikasi ringan yang memulihkan observabilitas.

Kesimpulan

Kebijakan RLS yang tersembunyi dapat mengubah antrean yang sibuk menjadi jalan buntu yang sunyi, membuat agen AI menjadi tidak aktif sementara pekerjaan menumpuk. Berikan hak istimewa bypass yang tepat kepada service role dan pasangkan setiap pembacaan antrean kosong dengan pemeriksaan canary; tim dapat menjaga keandalan pekerja otonom mereka dan menghindari titik buta yang merugikan.