Go'da Buffered HTTP Client Yazarken Karşılaşılan İki Kritik Bug

Go SDK'larında bellek içinde event biriktirip arka planda batch halinde göndermek yaygın bir pattern. Fakat bu mimarinin iki tuzağı var; bir geliştirici bu ay bunlarla karşılaştı ve deneyimini paylaştı.

Birinci sorun: Concurrent Close() çağrıları

İlk versiyonda Close() işlemi sync.Once ile korunuyordu. İlk çağrı buffer'ı drainlemek için zaman alırken, ikinci çağrı Once'ın zaten çalıştığını görüp hemen nil dönüyordu. Sorun şu: ikinci çağrı yapan kod (örneğin process'i kapatmak üzere olan bir goroutine) her şeyin flushed olduğunu sanıyor, ama ilk çağrı hâlâ in-flight event'leri gönderiyor. Sonuç: veriler kaybolabiliyor.

Çözüm basit ama etkili. İlk çağrı drain işlemini tamamlıyor ve hatayı kaydediyor, sonra bir channel kapatıyor. Sonraki çağrılar bu channel'da block oluyor ve aynı hatayı alıyorlar. Böylece herkes aynı sonucu görüyor.

İkinci sorun: Retry deadline'ları

Retry mekanizması eklenince deadline yönetimi karmaşık hale geliyor. Özellikle context timeout'lar ve exponential backoff birleştiğinde, deadline'lar çakışabiliyor veya çok kısa kalabiliyor.

Bu tür sorunlar sadece SDK'lara değil, herhangi bir buffering ve retry mantığı içeren client'a uygulanabilir. Concurrent shutdown, drain işlemleri ve timeout yönetimi yazarken dikkat edilmesi gereken standart noktalar.