Satu perintah cek status gate
Cek status gate Plane yang dulu butuh empat round trip MCP dan payload 86KB, sekarang cukup satu skrip read-only dengan exit code semantik.
Ringkasan
Dulu cek status ribet banget harus empat kali panggilan MCP cuma buat baca data 86KB yang loadingnya lama. Sempat kepikiran pakai cache tapi malah bikin pusing, akhirnya bikin skrip plane status yang baca langsung tanpa cache dan ngecek empat bagian secara paralel. Sekarang cukup satu perintah udah ketahuan beres atau nggak lewat kode exit-nya, jadi nggak males lagi ngecek gate.
Dulu, tiap mau mulai sesi kerja, ritual saya selalu sama: buka board, tunggu loading, lalu jalanin serangkaian panggilan MCP cuma buat mastiin semua masih sesuai aturan. Empat kali round trip bolak-balik, dan satu payload work-item seberat 86KB, itu semua cuma buat baca status. Rasanya kayak nyetir mobil yang harus di-starter lima kali sebelum mesinnya beneran hidup.
Tebakan Awal yang Meleset
Awalnya saya mikir, solusinya harusnya mindahin semua logika validasi ke dalam MCP itu sendiri. Atau minimal bikin lapisan cache biar nggak perlu narik data berulang-ulang. Logikanya kedengeran masuk akal: kalau datanya berat, ya simpen di lokal.
Tapi pas dicoba, pendekatan ini malah nambah kompleksitas. Cache bisa kedaluwarsa. Sinkronisasi state antara MCP dan board utama malah bikin bingung baru. Saya ngabisin waktu lebih banyak buat mastiin cache tetap akurat daripada kerja inti sendiri.
Ternyata, yang perlu diganti cuma sisi pembacaan dari gate itu. Mutasi state atau nambah komentar bukti tetap lewat MCP, sesuai desain awal. Dan buat baca status, ambil data segar tiap kali ternyata jauh lebih enak daripada ngurus cache yang bisa aja usang.
Baca Segar, Eksekusi Paralel
Jadi saya tulis scripts/plane_status.py. Satu skrip, satu pass REST read-only, tanpa cache. Empat pemeriksaan bagian dijalankan paraleel pakai ThreadPoolExecutor dari modul concurrent.futures [5], yaitu work items, kesegaran keputusan, mirror Pages, dan modul. Karena jalan barengan di pool thread, waktu tunggunya jauh lebih pendek dibanding ngecek satu per satu.
Detail yang paling saya suka: exit code-nya semantik. Kode 0 berarti semua bersih. Kode 1 itu alarm, misalnya ada drift atau work-in-progress yang nembus batas 2. Kode 2 artinya infrastrukturnya yang bermasalah. Hasilnya gampang dibaca mesin, nggak perlu mata manusia memindai teks board.
Ada dua keunikan yang saya temui pas nulis. Pertama, Cloudflare suka blokir User-Agent bawaan python-urllib dengan error 1010, jadi skrip ini ngirim User-Agent curl aja. Kedua, skrip ini nge-probe kandidat base URL: coba loopback dulu, baru pindah ke tunnel kalo yang pertama nggak menjawab. Board-nya sendiri itu self-hosted Plane, platform manajemen proyek open-source [6] di belakang tunnel.
Satu lagi: pas dapet respons 429, skrip ini nurut header Retry-After dari server [4]. Jadi dia nunggu sesuai instruksi server, bukan ngebanjiri dengan permintaan ulang.
Gate yang Murah Dicek Itu yang Dirawat
Gate yang nggak bisa dicek dengan satu perintah, ujungnya gate yang berhenti dicek. Bagian paling mahal dari sebuah gate bukan aturannya, tapi friksi pas kita harus lihat statusnya. Sekarang cukup satu perintah, dan saya langsung tahu apakah lingkungan kerja siap atau masih ada yang melenceng lebih dari toleransi drift 2 detik.
Saya sengaja simpen skrip ini lokal di repo internal, nggak dipindah ke repo utama proyek. Kebutuhan validasi bisa berubah cepat, dan fleksibilitas ini penting biar iterasinya nggak lambat. Kadang solusi terbaik bukan arsitektur paling canggih, tapi yang paling nggak menghalangi kita ngelakuin hal yang bener. Dan kuncinya: data yang selalu segar.
Sumber