Broken Pipe #

Dalam dunia backend, distributed system, dan network programming, error “broken pipe” adalah salah satu error klasik yang sering muncul namun kerap disalahpahami. Error ini biasanya muncul tiba‑tiba di log aplikasi, sering terjadi saat traffic tinggi, timeout, atau saat integrasi antar service.

Broken pipe bukan bug aplikasi murni, melainkan sinyal bahwa ada masalah pada koneksi komunikasi antar proses atau antar mesin.

Artikel ini akan membahas:

• Apa itu broken pipe
• Bagaimana proses terjadinya
• Gambaran besar (big picture) dalam bentuk bagan
• Penyebab umum
• Dampak ke sistem
• Best practices untuk mencegah dan menanganinya

Apa Itu Broken Pipe? #

Secara sederhana:

Broken pipe terjadi ketika sebuah proses mencoba menulis (write) ke koneksi yang sudah ditutup oleh pihak lawan.

Biasanya muncul dalam bentuk:

• Broken pipe (EPIPE)
• write: broken pipe
• SIGPIPE (di level OS)

Broken pipe sering ditemukan pada:

• HTTP client/server
• gRPC
• TCP socket
• Database connection
• Message broker

Gambaran Besar (Big Picture) #

Bagan Alur Terjadinya Broken Pipe #

Client                    Network                    Server
  |                          |                          |
  | ---- Request ----------> | ---- Request ----------> |
  |                          |                          |
  |                          | <--- Timeout / Close ----|
  |                          |                          |
  | <--- (Client unaware)    |                          |
  |                          |                          |
  | ---- Write Response ---> X (connection already closed)
  |                          |
  |                  ❌ BROKEN PIPE

Penjelasan #

1. Client mengirim request ke server
2. Server memproses request
3. Client atau server lebih dulu menutup koneksi (timeout, crash, load balancer, idle timeout)
4. Pihak lain masih mencoba melakukan write
5. OS mendeteksi pipe/socket sudah rusak → broken pipe

Broken Pipe di Level OS #

Di level Unix/Linux:

• Pipe / socket dianggap sebagai file descriptor

• Saat peer menutup koneksi:

  • Read akan return EOF
  • Write akan memicu SIGPIPE atau error EPIPE

Jika aplikasi tidak handle SIGPIPE dengan baik:

• Process bisa langsung crash

Penyebab Umum Broken Pipe #

1. Client Timeout Terlalu Pendek #

Client menyerah sebelum server selesai memproses.

Contoh:

• HTTP client timeout 2 detik
• Server butuh 5 detik

2. Load Balancer / Proxy Idle Timeout #

Load balancer (Nginx, Envoy, ALB) menutup koneksi idle.

Client ─── LB (idle timeout 60s) ─── Server (process 90s)

LB menutup koneksi, server masih menulis response → broken pipe.

3. Server Crash / Restart #

• Pod di Kubernetes restart
• OOMKilled
• Deployment rolling update

Connection lama mati, client masih mencoba write.

4. Connection Pool yang Tidak Sehat #

• Reuse koneksi lama
• Koneksi sudah mati tapi masih ada di pool

Biasanya terjadi di:

• Database client
• HTTP keep‑alive

5. Network Instability #

• Packet loss
• NAT timeout
• Firewall memutus koneksi idle

Dampak Broken Pipe ke Sistem #

• Error di log yang terlihat “random”
• Request gagal secara sporadis
• Latency spike (retry berulang)
• Resource leak jika tidak ditangani
• Crash process (jika SIGPIPE tidak di-handle)

Broken pipe sering menjadi gejala, bukan akar masalah.

Best Practices Menghadapi Broken Pipe #

1. Anggap Broken Pipe sebagai Normal Failure #

Dalam distributed system:

Network failure adalah hal normal, bukan exception langka.

Broken pipe harus diperlakukan sebagai:

• Recoverable error
• Bukan panic

2. Gunakan Timeout yang Seimbang #

Client #

• Jangan terlalu agresif
• Sesuaikan dengan SLA server

Server #

• Jangan menulis response setelah context timeout

Contoh (Go):

select {
case <-ctx.Done():
    return ctx.Err()
default:
    // write response
}

3. Handle SIGPIPE dengan Benar #

• Abaikan SIGPIPE
• Tangani error EPIPE secara eksplisit

Di banyak runtime modern (Go, Java):

• SIGPIPE sudah di-handle

Di C/C++:

• Perlu signal(SIGPIPE, SIG_IGN)

4. Defensive Write #

Sebelum write:

• Pastikan context masih hidup
• Pastikan connection valid

Prinsip:

Never assume the connection is still alive

5. Retry dengan Backoff #

Jika broken pipe terjadi di client:

• Retry
• Gunakan exponential backoff
• Batasi retry (max attempts)

Hindari:

• Retry tanpa delay
• Infinite retry

6. Healthier Connection Pool #

• Validasi koneksi sebelum reuse
• Gunakan keep‑alive ping
• Set max lifetime koneksi

Contoh:

• DB max lifetime < firewall idle timeout

7. Observability yang Baik #

Pantau:

• Error rate broken pipe
• Timeout rate
• Connection reset

Korelasi dengan:

• Deploy
• Autoscaling
• Traffic spike

Broken pipe yang meningkat tajam biasanya indikator masalah lain.

Anti‑Pattern yang Harus Dihindari #

❌ Panic setiap ada broken pipe ❌ Menganggap broken pipe sebagai bug aplikasi ❌ Menambah timeout tanpa batas ❌ Retry tanpa backoff ❌ Ignore log tanpa analisa tren

Ringkasan #

• Broken pipe terjadi saat write ke koneksi yang sudah ditutup
• Umum terjadi di sistem terdistribusi
• Biasanya gejala, bukan akar masalah
• Harus ditangani secara defensif
• Best practice fokus pada timeout, retry, observability, dan resilience

Jika sistem Anda tidak pernah mengalami broken pipe, justru patut dicurigai — kemungkinan error‑nya tidak terlihat 😉