Kontrollü kapanış

Consumer kapanışı yeni iş kabulünü durdurur, kabul edilmiş işi ve scope cleanup’ını uzlaştırır, broker kaynaklarını kapatır ve sahip olduğu application kaynaklarını sonlandırır. Bir cancel veya abort isteği, bu işlerin tamamlandığının kanıtı değildir.

Tek application bütçesi seçin#

[lifecycle]
shutdown_timeout_secs = 30

Varsayılan toplam süre 30 saniyedir. Bütçe ilk shutdown initiation anında başlar; supervisor’ın daha geç poll edilmesi onu yenilemez. Graceful ve force aynı hard root deadline’ı paylaşır. Framework reserve’i toplam sürenin dörtte biri ile 2 saniyenin küçük olanıdır; her aşamaya ayrı 30 saniye eklenmez.

Deployment termination süresini uygulamanın kaynakları ve bu bütçeyle uyumlu seçin. Delivery’nin kendi reserve’i ayrı bir hesaplamadır ve application root ile kısalır; ayrıntısı deadline sayfasındadır. Startup rollback da ortak attempt bütçesine bağlanır; pending DI rollback için bağımsız ek bir 30 saniye vaat edilmez.

Kapanışın izlediği sıra#

1. Yeni registration, intake ve execution admission kapanır.
2. Kabul edilmiş delivery pipeline’ları, transaction/relay işleri, scope cleanup ve settlement drain edilir.
3. Gerekirse bounded cooperative force ve gerçek task join’leri gözlenir.
4. Queue/channel/connection close kanıtları toplanır.
5. Owned DI ve outstanding kullanıcı/scope barrier’ları, signal monitor ve owned telemetry tamamlanır.
6. Immutable terminal sonuç ve varsa orijinal shutdown raporu yayımlanır.

Dış container veya external telemetry için Consumer disposal sahipliği iddia etmez. Üst uygulama önce Consumer dahil tüm kullanıcıları beklemeli, sonra o ortak kaynakları kapatmalıdır. Application’ın doğrudan oluşturduğu task ve kaynaklar da kendi owner’ı tarafından cancel/join edilmelidir.

Trigger ve force davranışı#

Sinyal tabanlı run() yolunda Unix SIGINT/SIGTERM graceful kapanış ister; SIGQUIT veya sonraki sinyal bounded force escalation tetikler. Token ve managed yollar OS listener’ı kurmaz. .shutdown().await graceful istek ve retained sonucun gözlemidir; işlem uzarsa framework’ün deadline koordinasyonu devreye girer.

Force bildirimi sağlıklı channel’da settlement yetkisini anında kaldırmaz; cooperative tamamlanan delivery kalan sürede ACK alabilir. Final abort gerektiğinde settlement authority revoke edilir ve task termination gözlenir. Abort isteğini task join veya remote ACK/COMMIT kanıtı olarak yorumlamayın.

Raporu hata sonucunda da okuyun#

use lilyrs::consumer::{ConsumerError, ManagedConsumer};

async fn stop(consumer: &ManagedConsumer) -> Result<(), ConsumerError> {
    let result = consumer.shutdown().await;
    if let Some(report) = consumer.shutdown_report() {
        println!("completion={:?}, successful={}", report.completion, report.is_success());
        println!("joined={}, queue_closed={}",
            report.runtime_joined, report.queue_close_reconciled);
    }
    result
}

snapshot().shutdown.completed, gerçek managed task join oldu demektir; bütün kaynaklar başarıyla kapandı demek değildir. report.is_success() ancak tamamen uzlaştırılmış başarılı graceful/forced kapanışta true olur. Rapor runtime join’den önce None döner; coordinator kanıtı üretilemeden failure varsa sonrasında da olmayabilir. Eksik rapor başarı değildir.

Orijinal kanıtı ve teknik sınırları koruyun#

Resource raporundaki owned, started, terminal, succeeded farklıdır: disposer hata dönse de gerçekten bitmişse terminal olabilir. Caller-owned/absent kaynaklarda alanlar false kalır. Force sonradan bitti diye önceki timeout/panic silinmez; geç tamamlanan cleanup immutable raporu yeniden yazmaz.

Yield etmeyen senkron kod veya blocking destructor async deadline ile preempt edilemez. Incomplete owner kaynak tutmaya devam edebilir; framework bu durumu başarılı kapanış gibi sunmaz. Runtime’ı Drop’tan hemen sonra kapatmak yerine managed örnekteki gibi açık sonucu bekleyin.