PyPI, iki hafta süren indirme 502 hatalarını bir Fastly canary hatasına ve kendi CDN yapılandırma kusurlarına bağlıyor

PyPI, Ağustos 2026'da files.pythonhosted.org üzerinden yapılan paket indirmelerini bozan, yaklaşık iki hafta süren aralıklı 502 ve 503 hatalarını açıklayan ayrıntılı bir olay raporu yayımladı. 8 Eylül'de PyPI blogunda paylaşılan rapor, başarısızlıkları birbiriyle ilgisiz iki nedene bağlıyor: bir canary deployment sırasında ortaya çıkan, Fastly ağındaki yanlış yapılandırılmış bir cache düğümü ve yalnızca inceleme sırasında gün yüzüne çıkan, PyPI'nin kendi Fastly yapılandırmasındaki birkaç uzun süredir var olan hata. İkisi de düzeltildi ve indirmeler 28 Ağustos'ta tam olarak çalışır hale geldi.

PyPI paket dosyalarını nasıl sunuyor

Rapora göre files.pythonhosted.org, üç origin'in önünde bulunan bir Fastly CDN servisi. Yüklenen dosyalar önce kalıcı ana kopyanın tutulduğu Amazon S3'e yazılıyor ve arka planda çalışan bir iş onları Backblaze B2'ye senkronize ediyor. Fastly ile Backblaze arasındaki, egress'i ücretsiz kılan bir anlaşma nedeniyle B2 tercih edilen okuma yolu. B2 başarısız olursa Fastly'nin S3'e geri dönmesi gerekiyor; PyPI, S3'ü daha yüksek geri alma maliyetiyle Glacier Instant Retrieval depolama sınıfında tutuyor. Paket dosyaları hiçbir zaman değişmiyor ve yaklaşık 11,5 yıllık bir cache ömrü taşıdığı için cache'lenmiş istekler hiçbir origin'e ulaşmıyor. Üçüncü bir backend olan Conveyor ise öngörülebilir URL'ler ve eski yönlendirmeler gibi paket dışı istekleri ele alıyor.

Bu failover tasarımı ancak edge katmanı B2'nin başarısız olduğunu fark ederse işe yarar ve aşağıda anlatılan hatalardan biri, bunun her zaman gerçekleşmediğiydi.

Kötü bir Fastly cache düğümü

Sorun, Fastly'nin kendi hesabına göre 15 Ağustos'ta Seattle bölgesindeki tek bir cache düğümünde başladı; bu tarih PyPI'nin destek takibine yapılan bir kullanıcı bildirimiyle de doğrulandı. Fastly, filosunun yeni cache ve yönlendirme yazılımını daha geniş dağıtımdan önce çalıştıran bir diliminden oluşan bir canary cohort'u işletiyor ve PyPI trafiği yıllardır bunun parçasıydı. Bir canary deployment sırasındaki kısmi geri alma, Seattle point of presence'indeki cache yapılandırmasını eski haline döndürürken önündeki yönlendirme yapılandırması döndürülmedi ve bu uyumsuzluk, yönlendirme katmanının o düğüme ulaşan tüm trafiğe 502 döndürmesine yol açtı.

Kalıcı 502 hatalarına ilişkin iki kullanıcı bildirimi 17 Ağustos'ta geldi. 18 Ağustos'taki üçüncüsünde, altı saat içinde ve 32 birbirinden ilgisiz paket arasında kaydedilmiş 88 adet 502'yi gösteren bir yeniden üretime yer alıyordu; bunlar arasında yükleyicilerin PEP 658 metaverisini okumak için kullandığı küçük .whl.metadata range istekleri de vardı — oysa PyPI'nin kendi loglarında o noktada önemli bir şey görünmüyordu. 19 Ağustos'ta gelen başka bir bildirim, hatayı x-served-by yanıt başlıklarını kullanarak belirli bir düğüme, cache-pae2080020'ye daralttı: oraya yönlendirilen her istek 19 saatten uzun süre başarısız oldu. Fastly'nin ağ operasyonları ekibi ardından PyPI trafiğinin bir dilimini etkilenen konuma gönderen bir yönlendirme override'ını kaldırdı ve 20 Ağustos'ta düzelme gözlendi. Fastly, altta yatan canary hatasını 28 Ağustos'ta yamaladı ve PyPI dahil tüm Python Software Foundation trafiğini canary programının dışına çıkardı; PyPI, daha net kontroller ve bildirimler sağlanması halinde nihayetinde programa yeniden katılmak istediğini belirtiyor.

PyPI'nin kendi yapılandırmasındaki hatalar

İnceleme sırasında PyPI ekibi, aynı belirtileri üreten kendi hatalarını da ortaya çıkardı: yükselen 502'ler ve dışarıdan 502 gibi görünen birkaç 501. En önemlisi origin fallback'teydi. S3 arşivine yeniden deneme yalnızca B2 bir hata durumu koduyla yanıtladığında çalışıyordu; B2 hiç yanıt vermezse — bir timeout, reddedilen bağlantı veya TLS hatası — Fastly sentetik bir 503 üretiyor ve yeniden denemeyi tamamen atlıyordu. 18 Ağustos'ta birleştirilen düzeltme, eksik arşim denemesini ekledi.

Bir başka sorun kümesi, PyPI'nin kısmi içerikli bir Range isteğine hizmet etmek için bütün büyük bir wheel'i cache'e çekmemek için kullandığı segmented caching ile ilgiliydi. Bu özellik, genel HTTP'dekinden daha az range sözdizimini destekliyor ve bytes=-1024 gibi sonek range'leri için sentetik bir 501 döndürüyordu — ki bu tam da bazı yükleyicilerin tüm dosyayı indirmeden wheel metaverisini okumak için gönderdiği istekti. PyPI, mantıksal olarak geçersiz range'ler gönderen tek bir istemciye izlenen bir sıçramanın ardından 21 Ağustos'ta sonek ve çoklu range isteklerini muaf tuttu ve 24 Ağustos'ta, bozuk iki paralel indirici tek günde 41.315 aynı sınıftan hata ürettikten sonra işlemeyi yeniden ayarladı. Rapor, bozuk bir istemci isteği için 501 döndürmenin yanlış durum sınıfı olduğunu söylüyor ve bir Fastly destek talebinin açık olduğunu, bunun ardından geçici çözümün muhtemelen geri alınabileceğini belirtiyor.

28 Ağustos'ta düzeltilen son hata bir sıralama sorunuydu: segmented caching muafiyet kontrolü, istek URL'si normalize edilmeden önce çalışıyordu, bu yüzden sorgu dizisi taşıyan bir .metadata isteği muafiyetten kaçıyordu — ve kötü bir segmented caching yanıtı cache'lenip aynı dosya için sonraki her isteğe sunulabiliyordu.

Neden önemli

PyPI, Python ekosisteminin varsayılan kurulum kaynağı; dolayısıyla edge hataları, gerçek arızadan çok uzakta, CI pipeline'larında ve dağıtımlarda rastgele, yeniden üretilemeyen başarısızlıklar olarak ortaya çıkıyor. Rapor, görünmez altyapının ne kadar fazla şeyinin — fallback sıralaması, range işleme, URL normalizasyonu — bir backend aksamasının emilip emilmeyeceğini yoksa kullanıcıya görünür hale gelip gelmeyeceğini belirlediğini ve yamalayamayacağınız bir bağımlılığın yine de kesintiniz olabileceğini gösteriyor. Ayrıca bu bir şeffaflik örnek olayı: PyPI, kullanıcı bildirimlerine bir satıcı tarafı arızasını tek bir makineye kadar daraltma konusunda itibar ediyor ve Fastly da kök nedeni paylaştı.