Backend terdistribusi Iroh 1.0 mengalami gangguan saat salah satu layanan tidak bisa melakukan dial ke node lain setelah penambahan kontrol akses kunci TLS. Penyebab utama bukan latency atau IP drop, melainkan asumsi bahwa backend harus langsung mendial IP tertentu. Artikel ini menunjukkan penyebab, diagnosis dengan telemetri, dan perbaikan riil agar koneksi kembali stabil.

Gejala dan observasi awal

Bug mulai terlihat setelah rollout fitur otentikasi kunci: permintaan RPC ke layanan broker-state timeout dengan pesan
dial tcp timeout. Node lain bisa diakses via HTTP, namun proses internal Rust tidak memutuskan koneksi.

Telemetri observability (tracing + metrik) menyorot dua hal:

  • Tracer span menunggu di panggilan connect selama 60 detik sebelum gagal.
  • Service mesh tidak menunjukkan perubahan routing—request tetap sampai pod target.
  • Log TLS mencatat sertifikat valid, tapi tidak ada sesi TLS terbentuk di backend.

Pola ini mengarahkan tim pada kode koneksi yang secara eksplisit mendial ke IP, bukan ke kunci layanan yang digeneralisasi lewat service discovery.

Kasus Iroh 1.0: asumsi dial IP

Dalam arsitektur Iroh 1.0, setiap backend Rust menggunakan registry kunci bernama PortMap untuk menemukan kunci TLS publik node lain. Era sebelum mesh, kode menggunakan struktur seperti berikut di modul transport::connect:

let addr = format!("{ip}:{port}");
let stream = TcpStream::connect(addr)?;

Sistem baru menempatkan IP kontainer di bawah kontrol orkestrator, sementara kunci TLS identik per layanan. Rule baru memutuskan bahwa setiap dial harus menggunakan kunci (misalnya broker-state) agar mesh dapat menyediakan endpoint aktual di sisi client. Karena kode masih memaksa dial ke IP literal, saat IP berubah akibat scaling atau failover, klien tidak pernah beralih ke endpoint valid.

Diagnosis praktis dan reproduksi minimal

Berikut langkah untuk memverifikasi bug di lingkungan staging:

  1. Jalankan kluster Iroh lokal dengan dua node: client dan broker-state.
  2. Matikan service discovery (misalnya konfigurasi gRPC name resolver) sehingga klien harus rely pada IP statis.
  3. Scaling down pod broker-state dan restart di IP baru; klien akan tetap mencoba ke IP awal dan menemui timeout.

Reproduksi minimal bisa dibuat lewat two-node setup Rust: satu thread listener menunggu kunci TLS (misalnya file /tmp/broker.pem), client memanggil resolver kunci tapi tetap dial IP lama. Eksekusi akan timeout di TcpStream::connect.

Memeriksa trace menunjukkan span transport::connect berulang-ulang gagal sebelum mencoba resolver.

Perbaikan: Dial berdasarkan kunci/alias layanan

Pada inti perbaikan adalah mengganti kode yang hardcode IP dengan fungsi resolver kunci yang mengembalikan alamat aktual. Prinsipnya: siapa pun yang membutuhkan broker-state memanggil resolver kunci dan mendapat endpoint dinamis.

  1. Resolver kunci: Tambahkan modul key_resolver.rs yang memetakan nama layanan ke Multiaddr atau SocketAddr aktual melalui registry internal.
  2. Koneksi dinamis: Ubah pemanggilan TcpStream::connect menjadi loop yang membaca dari resolver.

Contoh snippet:

let target = resolver.resolve("broker-state")?;
for endpoint in target.endpoints() {
    if let Ok(stream) = TcpStream::connect(endpoint).await {
        return Ok(stream);
    }
}
Err(anyhow!("gagal dial broker-state"))

Loop paling atas menjaga agar klien mencoba endpoint yang valid di service mesh. Resolver bisa memanfaatkan gossip registry dari Iroh 1.0 agar informasi endpoint selalu konsisten.

Setelah kode di-update, jalankan kembali cargo test dan deployment suite untuk memastikan tidak ada konfig lain yang masih memaksa IP.

Konfigurasi dan rerun test

Pastikan konfigurasi environment mengatur kunci layanan sebagai nama DNS/kunci, bukan IP. Contoh config.toml snippet:

[transport]
target_key = "broker-state"

Kemudian jalankan:

  1. cargo test --package transport untuk memastikan resolver tercover.
  2. Deploy ke staging dan amati trace span & log connection success.
  3. Gunakan tool seperti grcov untuk memastikan area baru ter-instrument.

Jika masih terjadi timeout, periksa apakah registry kunci menerima update endpoint (telemetri new target discovery).

Mitigasi jangka panjang dan pengamatan tambahan

Untuk mencegah regresi sejenis:

  • Integrasikan unit tests yang memverifikasi koneksi berbasis kunci dengan mocked resolver.
  • Tambahkan manual observability: span khusus di resolver, metrik discovery-misses.
  • Gunakan canary deployment saat menambahkan node baru agar perubahan endpoint tidak meledak di produksi.

Selain itu, tinjau apakah sistem lain masih memakai IP statis. Jika ada, prioritaskan migrasi ke service discovery berorientasi kunci agar mesh dan TLS tetap konsisten.

Dengan pendekatan ini, developer Iroh 1.0 bisa memastikan backend tetap robust saat IP node berubah, karena koneksi sekarang berbasis kunci identitas layanan, bukan alamat fisik yang mudah berganti.