Breaking Changes: v0.0.79

v0.0.79, yetkilendirme yüzeylerini tek bir grant değerlendirme çekirdeğinde birleştirir, sessizce bozuk çalışan doğrulamaları düzeltir ve transition kilitleme modelini Busy-as-mutex ile değiştirir. Bu değişikliklerin bir kısmı gözlemlenebilir davranışı değiştirir. Aşağıdaki maddeleri sürüm geçişinden önce gözden geçirin.

Breaking Changes

1. x-roles DENY artık tüm grant seti genelinde uygulanıyor

Etkilenen Alan: Şema x-roles alan bazlı görünürlük (vnext #860)

Önceki Davranış: Ön tanımlı bir rolü hedefleyen DENY grant'ı, çağıran alakasız herhangi bir role sahipse deliniyordu — o rol hiçbir grant'la eşleşmiyor, set blacklist kuralına düşüyor ve alan görünür kalıyordu.

Yeni Davranış: DENY, grant setinin tamamı genelinde değerlendirilir ve her zaman ALLOW'u ezer. Önceki açıktan yararlanarak görünür kalan alanlar artık gizlenir. Yön: daha kısıtlayıcı.

Migration: x-roles içinde DENY kullanan domain'ler alan görünürlüğünü yeniden test etmeli; bir alanın "yanlışlıkla görünür" olmasına dayanan client davranışı varsa düzeltilmeli.

2. x-roles yalnızca-DENY setler rolsüz çağırana görünür

Etkilenen Alan: Şema x-roles alan bazlı görünürlük (vnext #860)

Önceki Davranış: Rolü hiç çözümlenemeyen (ör. yalnızca legacy role header'ı taşıyan) bir çağıran, yalnızca DENY içeren bir set karşısında bile alanı göremiyordu.

Yeni Davranış: Kanonik blacklist semantiği uygulanır: yalnızca-DENY bir set, DENY'a takılmayan herkese (rolsüz çağıran dahil) izin verir. ALLOW listesi içeren setler etkilenmez. Yön: daha permissive.

Migration: Rolsüz bir çağırana asla ulaşmaması gereken alanlara açık bir ALLOW listesi tanımlayın — yalnızca DENY ile koruma yapmayın.

3. Human-task listesi execution ile aynı kurala geçti

Etkilenen Alan: Human-task (kullanıcı görev listesi) filtreleme (vnext #860)

Önceki Davranış: Liste, statik ve ön tanımlı rol eşleşmesini birlikte şart koşuyor, dynamic grant'ları yok sayıyor ve behalf-of grant'larını yanlış kimlik alanıyla karşılaştırıyordu — kullanıcının çalıştırabildiği bir transition listede görünmeyebiliyordu.

Yeni Davranış: Liste, transition execution ile aynı herhangi-bir-ALLOW-eşleşir kuralını uygular ve dynamic grant'ları tanır. Yön: daha permissive — kullanıcının zaten çalıştırabildiği görevler artık listede görünür.

Migration: Görev listesi hacmine duyarlı ekranlar varsa (ör. süpervizör panoları) liste büyümesini gözlemleyin; yetki daralması gerekiyorsa roles tanımlarını gözden geçirin.

4. Dynamic role grant sözdizimi doğrulaması artık gerçekten hata üretiyor

Etkilenen Alan: Component doğrulama — tüm transition tipleri (vnext #859)

Önceki Davranış: ValidateRoleGrants hiç hata üretemiyordu. $user.$.Context.ownerId gibi büyük/küçük harf hatalı ya da bozuk bir dynamic grant, doğrulamadan geçiyor ve çalışma zamanında sessizce etkisiz kalıyordu (asla eşleşmeyen bir ALLOW ya da asla engellemeyen bir DENY).

Yeni Davranış: Bozuk dynamic grant'lar ($user./$role. ile başlayıp geçerli forma uymayanlar) deploy sırasında doğrulama hatası üretir. Statik rol adları ve dört ön tanımlı instance rolü serbest biçimli kalır.

Migration: Sürüme geçmeden önce mevcut domain paketlerini tarayın: $user. / $role. / $.context. içeren tüm roles tanımlarının sözdizimini kontrol edin. Önceden sessizce etkisiz olan grant'lar deploy'u durduracaktır.

5. Well-known transition'lar execution'da availableIn ile sınırlandı

Etkilenen Alan: cancel / updateData / exit transition execution (vnext #870)

Önceki Davranış: availableIn yalnızca discovery'yi etkiliyordu; cancel, updateData ve exit, availableIn ne derse desin her state'ten POST edilebiliyordu.

Yeni Davranış: Execution da state gate uygular: availableIn kapsamı dışındaki bir state'ten gelen istek Transition:100024 ile reddedilir. Error-boundary bypass korunur.

Migration: Well-known transition'ları availableIn dışındaki state'lerden çağıran client/otomasyon akışlarını tespit edin; ya availableIn kapsamını genişletin ya da çağrıyı doğru state'e taşıyın.

6. Orchestration host href'leri /api/{domain} → /api/v1/{domain}

Etkilenen Alan: UrlTemplates yapılandırması ve client'lara dönen href'ler (vnext #871)

Önceki Davranış: Orchestration host /api/{domain}/… şablonları ile yapılandırılmıştı — route'ların gerçekte gerektirdiği v1 segmentini atlıyordu; üretilen href'ler uygulamanın kendisinin 404 verdiği bir yolu işaret ediyordu.

Yeni Davranış: UrlTemplates tek bir BasePath ayarına indirgendi; bölüm tamamen atlanırsa varsayılan /api/v1 kullanılır. Orchestration host href'leri artık /api/v1/{domain}/… üretir. Monitor href'leri (/api/v1/monitor/…) değişmedi.

Migration: Gateway'iniz gerçekten /api/{domain}/… rotası servis ediyorsa host'a şunu ekleyin:

"UrlTemplates": { "BasePath": "/api" }

Eski tam-şablon stilinde yazılmış herhangi bir override (env var dahil) verbatim kullanılmaya devam eder — BasePath öne eklenmez. Ayrıntı: URL Templates.

7. updateData / exit görünürlüğü instance listelerini hafifçe genişletir

Etkilenen Alan: availableTransitions ve instance list sorguları (vnext #859)

Önceki Davranış: Instance list filtreleri "çağıranın yetkili olduğu en az bir transition" kuralında yalnızca state/shared transition'ları ve cancel'ı sayıyordu.

Yeni Davranış: updateData ve exit de sayılır: tek yetkili transition'ı rolsüz bir exit olan instance, önceden görünmezken artık listede görünür. (cancel için bu davranış zaten geçerliydi; tutarlılık için genişletildi.)

Migration: Instance listelerinin daralmasına dayanan raporlama/ekran varsa sonuç kümelerini doğrulayın; görünürlüğü daraltmak için exit / updateData transition'larına roles tanımlayın.

8. Chain-token kilidi kaldırıldı — Busy artık yürütme mutex'i

Etkilenen Alan: Transition kabulü ve eşzamanlılık (vnext #877)

Önceki Davranış: Transition yürütmesi uzun lease'li (330 sn) dağıtık chain-token kilidiyle korunuyordu; eşzamanlı istekler kilit üzerinde bekleyebiliyor, kilit kaçakları preprod'da DB-pool tükenmesine kadar kaskatlanabiliyordu.

Yeni Davranış: Busy durumu yürütme mutex'inin kendisidir. State/shared transition'lar instance Busy iken 409 alır; cancel/exit busy check'ten muaftır; kabul sonrası pipeline kilitsiz çalışır. ChainToken/ChainLockRegistry/ChainReaper kaldırıldı, kolonlar migration ile düşer. Bilinen ödünleşim: sync path'te pod çökerse instance, async job recovery devralana kadar Busy kalır.

Migration: 409'u kilit beklemesi gibi yeniden deneyen client'ları gözden geçirin: Busy çakışmasında 409 artık beklenen yanıttır. Instance aktifken paralel veri basan akışları updateData'ya taşıyın (madde 9).

9. updateData semantiği değişti — status-neutral, subflow'a forward yok

Etkilenen Alan: updateData transition davranışı (vnext #877)

Önceki Davranış: updateData Busy durumuna takılabiliyor ve instance'ı Busy'de bırakabiliyordu; aktif subflow varken istek subflow'a yönlendirilebiliyordu. Durable ResumePoint checkpoint'i retry'larda kaldığı yerden devam ettiriyordu.

Yeni Davranış: updateData koşulsuz kabul edilen, status-neutral bir reserve transition'dır: Busy'yi ne set eder ne çözer. Düz instance'ta normal pipeline'ı çalıştırır (auto'lar her updateData sonrası, order 90'da değerlendirilir); aktif subflow'da olsa bile istek parent'ta karşılanır ve subflow'a forward edilmez — parent datası güncellenir ve bırakılır. ResumePoint kaldırıldı: retry'lar pipeline'ı baştan çalıştırır; mükerrer koruması transition-record guard'ı ve task journal'dadır.

Migration: Subflow'a updateData forward edilmesine dayanan akışlar varsa, subflow'un kendi updateData tanımına doğrudan (subflow instance'ına) istek atın. Paralel updateData altında mapping'leri delta-only çıktı verecek şekilde gözden geçirin; aynı order'daki paralel branch'lerde farklı task tanımları kullanın. Ayrıntı: Workflow → Transition Yürütme Modeli.

10. InstanceData yazım modeli — anlık kalıcılık, HistorySequence kaldırıldı

Etkilenen Alan: Instance data versiyonlama ve kalıcılık (vnext #877)

Önceki Davranış: InstanceData yazımları DbContext seviyesinde tek noktadan, geciktirilmiş şekilde kalıcılaşıyordu; versiyon kimliği DB trigger'ı ve in-memory rebase makinesiyle üretiliyordu. Çökme, task çıktısını kaybedebiliyor; versiyon kimliği yarışabiliyordu.

Yeni Davranış: Her InstanceData satırı üretildiği anda kalıcılaşır; satır kimliği (VersionNo = MAX(VersionNo)+1, head + strateji, içerik hash dedup'u) instance başına FOR UPDATE kilidi altında hesaplanır. DB versioning trigger'ı, Instance.AddData/AddDataWithVersion ve HistorySequence kolonu kaldırıldı (migration'lar geri alınabilir). Kabul edilen her updateData iki data satırı üretir (istek payload'ı + task çıktısı).

Migration: HistorySequence kolonuna veya data satırlarının tek-batch yazılmasına dayanan raporlama/entegrasyon varsa VersionNo sıralamasına geçin. Rolling deploy güvenlidir: overlap penceresinde trigger ve servis aynı MAX+1 değerini atar.

---

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

vNext Runtime Platform Team