Ana içeriğe geç

Breaking Changes: v0.0.92

· 6 dakikalık okuma
vNext Team
vNext Team
Burgan Tech Engineering

v0.0.92, incident'ları kendi tablosuna taşır ve instance metadata'sındaki incident bloğunu link-only bir şekle çevirir; ayrıca retry/unfault üzerindeki üç davranış hatasını düzeltir, DbMigrator'a timeout/lock yapılandırması ekler, discovery cache'i devreye alır ve Busy admission'ı Postgres CAS'a taşır. Aşağıdaki maddeleri sürüm geçişinden önce gözden geçirin.

Breaking Changes​

Etkilenen Alan: GET .../instances/{instance} ve liste görünümlerindeki metadata.incident (vnext #972)

Önceki Davranış: metadata.incident, embed edilmiş aktif incident'ı, en yeni 5 kaydı içeren inline bir history array'ini, bir totalCount alanını ve düz bir href'i taşıyordu.

Yeni Davranış: metadata.incident artık { hasActiveIncident, active: { href }, history: { href } } şeklinde — state function'ın incident bloğuyla byte-for-byte aynı şekil. active, yalnızca bayrak true iken bulunur. Embed edilmiş aktif incident, inline newest-5 array'i, totalCount ve düz href kaldırıldı. Yön: daha kısıtlayıcı.

Migration: metadata.incident.active/history/totalCount/href alanlarını okuyan client'ları active.href ve history.href üzerinden ayrı bir GET yapacak şekilde güncelleyin.

2. GET .../incidents/active'ten 404 dönmesi normal bir yanıt​

Etkilenen Alan: GET .../instances/{instance}/incidents/active (vnext #972)

Önceki Davranış: Aktif incident her zaman ana instance yanıtına gömülü olduğu için ayrı bir "aktif incident yok" durumu yoktu.

Yeni Davranış: active.href, bayrak set iken reklamı yapılır, ancak bir retry incident'ı tam o sırada çözebilir; bu durumda endpoint 404 Instance:100037 döner. Bu normal bir yanıttır, hata değildir — role gate'i geçemeyen bir çağıran bunun yerine 403 alır. Yön: davranış değişikliği.

Migration: Client'larınızı 404'ü "incident yok, state'i yeniden oku" olarak, 403'ü ayrı bir "yetkisiz" durumu olarak ele alacak şekilde güncelleyin.

3. Fault ile sonuçlanan bir retry artık kalıcı olarak F kalıyor​

Etkilenen Alan: POST .../instances/{instance}/retry (vnext #972)

Önceki Davranış: Yeniden yürütülen iş tekrar fault olduğunda yanıt 200 {"status":"F"} dönüyordu, ama instance arka planda Active'e geri dönüyordu (ambient request unit-of-work, iç bir RequiresNew scope'un persist ettiği Faulted'ı eziyordu) — instance sağlıklı görünen, işi bitmemiş ve bir daha retry edilemeyen (400 Instance:100027) bir duruma düşüyordu.

Yeni Davranış: Retry artık aggregate'i no-tracking okuyor ve compare-and-set ile unfault ediyor; yanıttaki "status":"F" artık kalıcıdır ve ikinci bir retry kabul edilir. Yön: daha kısıtlayıcı.

Migration: Bir F yanıtının ardından instance'ın Active görünmesine dayanan workaround/retry-loop mantığınız varsa kaldırın; retry yanıtındaki status'u kalıcı kabul edin.

4. unfault artık tüm açık incident'ları kapatıyor; sahte ErrorBoundaryAbort satırı yok​

Etkilenen Alan: Instance unfault / incident kaydı (vnext #972)

Önceki Davranış: Bir abort, biri boundary'nin verdict'i diğeri errorCode: "ErrorBoundaryAbort" taşıyan sahte bir pipeline-katmanı satırı olmak üzere iki incident kaydediyordu — daha yeni olan bu ikincisi active oluyor ve boundary'nin gerçek verdict'ini gizliyordu. Ayrıca başarılı bir retry yalnızca en yeni incident'ı çözüyordu; kurtarılan bir instance hasActiveIncident=true raporlamaya devam ediyor, bu bayrak fingerprint ETag'ının parçası olduğu için long-poll eden client'lar da bu bayatlığı görüyordu.

Yeni Davranış: Üç task adımı artık incident'ı kendi save'inden önce kaydediyor; satır ve HasActiveIncident bayrağı birlikte commit oluyor ve pipeline'ın fault path'i sahte satırını atlıyor — bir hata tam olarak bir incident bırakıyor, active her zaman boundary'nin verdict'i. unfault ve yeni bir fault olmadan tamamlanan bir boundary transition'ı artık instance'taki tüm açık incident'ları çözüyor ve bayrağı yeniden hesaplıyor. Yön: davranış değişikliği.

Migration: errorCode: "ErrorBoundaryAbort"'a göre filtreleme yapmayın (pipeline artık bu satırı yazmıyor; aynı string hâlâ abort eden bir boundary'nin döndürdüğü Result error code'udur) ve bir hata başına iki incident beklemeyin — tek incident'ın boundaryAction/boundaryLevel'ını okuyun. Kurtarma sonrası hasActiveIncident'ı doğrudan otoriter kabul edin, client tarafında resolved incident'ları filtrelemeyin.

5. Legacy Instances.Incidents jsonb kolonu donduruldu​

Etkilenen Alan: Veritabanı — Instances.Incidents jsonb kolonu (vnext #972)

Önceki Davranış: Instances.Incidents jsonb array'i (en yeni 5 kayıtla sınırlı) incident'ların tek kaynağıydı.

Yeni Davranış: Incident'lar artık ayrı InstanceIncidents tablosunda (sınırsız history, BackfillInstanceIncidents migration'ıyla geriye dolduruldu) tutuluyor. Legacy jsonb kolonu veritabanında unmapped olarak kalıyor ve migration öncesi içeriğinde donmuş durumda — bu sürümde silinmiyor, gelecekteki bir migration'da kaldırılacak. Yön: daha kısıtlayıcı.

Migration: Instances.Incidents jsonb kolonunu doğrudan sorgulayan bir entegrasyon/rapor varsa, yeni InstanceIncidents tablosuna veya GET .../incidents / GET .../incidents/active endpoint'lerine geçin — jsonb kolonu artık güncellenmiyor.

6. DbMigrator artık şema migration timeout/lock süresi konfigüre edilebilir ve hatada non-zero exit veriyor​

Etkilenen Alan: workers/BBT.Workflow.DbMigrator — SchemaMigration config'i (vnext #972)

Önceki Davranış: DbMigrator sabit bir command timeout kullanıyordu ve bir şema migration'ı fail olsa bile runner başarı raporluyordu.

Yeni Davranış: SchemaMigration:CommandTimeoutSeconds (varsayılan 600) ve SchemaMigration:LockExpirySeconds (varsayılan 900, timeout'u aşacak şekilde doğrulanıyor) eklendi; runner artık herhangi bir şema fail olduğunda non-zero exit code ile çıkıyor. Yön: davranış değişikliği.

Migration: Büyük tablolarda 600 saniyeden uzun süren migration'lar varsa SchemaMigration:CommandTimeoutSeconds'ı (ve üstünde LockExpirySeconds'ı) artırın. DbMigrator job'unuzun exit code'unu izleyen bir CI/CD adımı yoksa ekleyin — artık migration hataları sessizce yutulmuyor.

7. POST utilities/discovery/refresh senkron hâle geldi ve yeniden aktif; discovery cache orchestration host'ta açık​

Etkilenen Alan: POST .../utilities/discovery/refresh ve ServiceDiscovery:Cache (yalnızca Provider=http) (vnext #976)

Önceki Davranış: Discovery registry her cross-domain hop için canlı bir GET yapıyordu (caching yoktu, kasıtlı bir tasarım kararıydı); discovery/refresh endpoint'i deprecated'dı.

Yeni Davranış: ServiceDiscovery:Provider=http altında artık read-through bir cache var (in-process L1 + shared distributed L2, miss'te canlı registry) — yalnızca http provider'ını etkiler, dapr provider'ında hiçbir şey değişmedi. POST .../utilities/discovery/refresh un-deprecated edildi, artık senkron çalışıyor ve sonucunu raporluyor. Cache kod varsayılanında kapalı, ama orchestration host'un appsettings.json'ında açık. Yön: davranış değişikliği.

Migration: Bir domain'in baseUrl'ini değiştiren her deploy/operasyon sonrası POST .../utilities/discovery/refresh'i çağırın — cache penceresi (varsayılan 1 saat marker / 2 saat entry) taşınma durumunu otomatik yakalamaz. Runtime'ı paket olarak tüketip appsettings override'ı yapmayan host'lar kod varsayılanını (Cache:Enabled=false) korur; eski davranışı istemeden değiştirmiş olmazsınız. AcceptedStatuses varsayılanının (["A"]) registration workflow'unuzun bitiş state'iyle uyumlu olduğunu doğrulayın.

8. Instance status güncellemeleri artık distributed lock yerine Postgres CAS kullanıyor​

Etkilenen Alan: Transition admission / Busy durumu — InstanceBusyManager, TransitionAdmissionService (vnext #975)

Önceki Davranış: Instance status flip'leri (Busy set/clear) kısa süreli bir distributed lock (status lock) altında yapılıyordu; tamamlanmış bir parent instance'a subflow üzerinden gelen bir Busy sinyali yine de yayılabiliyordu.

Yeni Davranış: Status güncellemeleri artık Postgres compare-and-set ile yapılıyor, distributed lock'a ve gereksiz transaction'lara ihtiyaç kalmadı. Tamamlanmış (completed) bir parent instance artık subflow'undan gelen Busy durumunu yaymıyor — önceki bir hata düzeltildi. Yön: daha kısıtlayıcı.

Migration: Tamamlanmış bir parent'ın Busy'ye geçtiğini varsayan bir monitoring/test senaryonuz varsa güncelleyin; bu artık gerçekleşmiyor. Distributed lock timing'ine dayanan bir gözlem/log korelasyonu yapıyorsanız, admission artık CAS tabanlı olduğu için lock acquire/release span'larının bir kısmı ortadan kalkmış olabilir.

Bu sürümün tüm özellikleri için Release v0.0.92 notuna bakın.

vNext Runtime Platform Team