Breaking Changes​

1. metadata.incident artık içerik değil, link taşıyor​

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

Breaking Changes​

1. Bir auto-transition kazanırsa, o hop için scheduled timer hiç kurulmuyor​

Etkilenen Alan: Transition pipeline epiloğu — LifecycleOrder.Auto/LifecycleOrder.Schedule sırası (vnext #943)

Önceki Davranış: ScheduleTransitionsStep (order 80), RunAutomaticTransitionsStep (order 90)'dan önce çalışıyordu: state'in scheduled transition'ları için önce timer kuruluyor, sonra bir auto kazandıysa zincirlenen bir sonraki hop'un CancelScheduledJobsStep'i tarafından hemen iptal ediliyordu.

Yeni Davranış: Sıra değişti — Auto artık order 80, Schedule artık order 90. RunAutomaticTransitionsStep, Directives.NextTransition'ı seçtiyse ScheduleTransitionsStep hiçbir Dapr job'u/InstanceJob satırı kurmadan atlanır (ScheduledTransitionsSkippedForChainedNext, EventId 10156, Debug). Bir auto kazandığında, terk edilecek state için timer artık hiç kurulup iptal edilmiyor. Yön: davranış değişikliği.

Migration: State function'da geçici olarak görünen kind: "scheduled" girdilerine dayanan bir client/test senaryonuz varsa (auto'nun hemen kazandığı bir state'te), bu girdinin artık hiç görünmeyeceğini hesaba katın. ClearBusyOnResumeStep'in step order'ı Auto - 1 olarak (sayısal olarak hâlâ 79) yeniden tanımlandı — persist edilen hiçbir veri step order değerini taşımadığı için bu deploy-safe'dir.

2. Timer script'leri artık auto rule'lardan sonra çalışıyor; auto adımı fail olursa timer kurulmuyor​

Etkilenen Alan: Transition pipeline epiloğu — timer input script'leri (vnext #943)

Önceki Davranış: Timer script'leri (scheduled transition input'ları) auto-transition koşulları değerlendirilmeden önce çalışıyordu; auto adımı unhandled bir hatayla fail etse bile state'in timer'ları zaten kurulmuş oluyordu.

Yeni Davranış: Timer script'leri artık auto koşul script'lerinden sonra çalışır (auto değerlendirmesi instance data'yı mutate etmediği için timer input'ları değişmez). Auto adımının kendisi fail olursa (ör. unhandled non-blocking task failure), timer'lar da kurulmaz — instance zaten fault oluyor. Yön: davranış değişikliği.

Migration: Doğrudan bir aksiyon gerekmez; auto adımı fail eden bir state'te önceden "kurulup asla ateşlenmeyen" timer'lara dayanan bir gözlem/monitoring varsa (ör. faulted bir instance'ta hâlâ armed görünen scheduled entry), bu artık gözlemlenmeyecek.

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

vNext Runtime Platform Team

Breaking Changes​

1. Custom function çağrısında function.roles gate'i kaldırıldı​

Etkilenen Alan: Custom function invocation — FunctionAccessPolicy (vnext #927)

Önceki Davranış: Bir custom function çağrısı, hem scope (Domain/Flow/Instance) kontrolünden hem de function.roles rol kontrolünden geçmek zorundaydı.

Yeni Davranış: Rol gate'i custom function çağrılarından kaldırıldı — bu artık yalnızca authorize fonksiyonunun sorumluluğu. Scope kontrolü (Domain/Flow/Instance) değişmeden kalır; bu bir call-shape doğrulamasıdır, authorization değil. function.roles hâlâ onurlandırılır, ama artık yalnızca authorize fonksiyonu tarafından değerlendirilir. Yön: daha permissive.

Migration: Yalnızca function.roles'a dayanarak bir custom function'ı role-gate'lediyseniz, bu kontrolü artık authorize fonksiyonuna taşıyın — aksi halde önceden reddedilen bir çağrı artık geçebilir.

2. EventHook altyapısı kaldırıldı — tüm event'ler outbox üzerinden​

Etkilenen Alan: IEventPublishHook<T>, IEventHookInvoker, EventHookAttribute, EventHookMode (vnext #927)

Önceki Davranış: Distributed event publishing, transactional outbox'ın yanı sıra bir EventHook mekanizması (IEventPublishHook<T> implementasyonları) üzerinden de özelleştirilebiliyordu.

Yeni Davranış: EventHook altyapısı tamamen kaldırıldı. Her distributed event artık transactional outbox üzerinden gider; event bus yalnızca trace stamping'e indirgendi. Üç subflow terminal event'i (ISubflowTerminalEvent) artık post-commit'te SubflowTerminalRelay ile parent'ı hemen bir komut olarak settle ediyor; Inbox handler'ı ISubItemTerminalGuard ile dedupe edilen durable bir yedek olarak kalıyor. Yön: daha kısıtlayıcı.

Migration: IEventPublishHook<T> implementasyonu yazan bir domain/entegrasyon varsa, bu kod artık çağrılmıyor — event'i outbox'tan (pub/sub aboneliği) tüketecek şekilde yeniden yazın. Ayrıntı için vnext reposundaki docs/runtime/event-publish-modes.md'e bakın.

3. Execution imajının base'i Alpine'den .NET 10 Noble'a geçti​

Etkilenen Alan: Execution servisi container imajı (vnext #921)

Önceki Davranış: Execution imajı Alpine tabanlıydı (musl libc).

Yeni Davranış: Execution imajı, Python task desteğinin glibc/manylinux wheel'lerini tüketebilmesi için .NET 10 Noble (Debian tabanlı, glibc) base image'ına geçti. Yön: davranış değişikliği.

Migration: Execution imajını extend eden veya Alpine'e özgü paket/araç varsayımı yapan (ör. apk ile paket kuran) custom Dockerfile'ları/CI adımlarını Debian/Noble araçlarına (apt) göre güncelleyin. İmaj boyutu ve base katmanları değişti; kayıtlı SBOM/imza/attestation süreçleri buna göre güncellenmiştir.

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

vNext Runtime Platform Team

Breaking Changes​

1. ComponentCache:GenerationMemoSeconds kod varsayılanı 0'dan 5'e çıktı​

Etkilenen Alan: Component cache generation-token memoization (kod varsayılanı) (vnext #920)

Önceki Davranış: Kod varsayılanı 0'dı; v0.0.85'te yalnızca orchestration host'un appsettings.json'ında 5'e override edilmişti.

Yeni Davranış: GenerationMemoSeconds'ın kod varsayılanı da 5'e çekildi ve orchestration host'un appsettings override'ı kaldırıldı (artık gereksiz). Runtime'ı paket olarak tüketen ve appsettings override'ı yapmayan her host, artık publish sonrası en fazla 5 saniyelik bir cross-pod görünürlük penceresiyle karşılaşır. L1 cache bu riski taşımaz (L1 anahtarı token'ı içerir, bu yüzden L1 asla bayat kalamaz). Yön: davranış değişikliği.

Migration: Publish sonrası anlık cluster-wide görünürlük gereken host'larda ComponentCache:GenerationMemoSeconds'ı 0'a set edin. CI/CD'de publish sonrası smoke/cutover öncesi bekleme kuralınız yoksa ekleyin (bkz. Breaking Changes: v0.0.85).

2. Telemetry:Tracing:AdditionalSources'a yeni ActivitySource'lar eklenmeli, yoksa span'lar sessizce düşer​

Etkilenen Alan: Host telemetry config'i — Telemetry:Tracing:AdditionalSources (vnext #920)

Önceki Davranış: Pipeline'ın büyük kısmı (validation, context load, task input/invoke/output compile, subflow mapping, lock, component read) hiç span üretmiyordu; üretilenler de görece az ActivitySource altında toplanıyordu.

Yeni Davranış: Pipeline artık adım adım (Step.{Name}, Transition.LoadContext, Task.Invoke, Script.Compile, Cache.Get, Lock.Acquire, ...) span üretir; bunlar yeni ActivitySource'lar altında yayınlanır. Telemetry:Tracing:AdditionalSources bu yeni kaynakları listelemiyorsa, o kaynaklardan gelen span'lar sessizce hiç export edilmez. Yön: daha kısıtlayıcı.

Migration: Her host'un (Orchestration, Execution, Inbox/Outbox worker) Telemetry:Tracing:AdditionalSources listesini güncel BBT.Workflow.* kaynak listesiyle senkron tutun. Yeni bir span kaynağının trace'de görünmemesi genellikle bu listenin güncel olmadığının işaretidir.

3. IWorkflowContext kaldırıldı​

Etkilenen Alan: Runtime'ı paket olarak tüketen kod — IWorkflowContext (vnext #920)

Önceki Davranış: IWorkflowContext, artık silinmiş bir SchemaValidationAttribute aspect'i için eklenmişti ve o zamandan beri öksüz kalmıştı — yalnızca 2 writer, 3 reader ve ~15 test double'ı vardı. Kendi memo'su yalnızca Key'i karşılaştırıyordu; pinlenmiş bir versiyon isteği sessizce farklı bir versiyon dönebiliyordu.

Yeni Davranış: IWorkflowContext kaldırıldı. Üç okuyucusu artık workflow'u kendi çağıranından alıyor (PostCommitParentSnapshot, bir Workflow? parametresi); InstanceCommandAppService'in hatalı memo'su tamamen silindi. Yön: daha kısıtlayıcı.

Migration: Runtime'ı NuGet paketi olarak tüketip IWorkflowContext'i inject eden veya mock'layan kod varsa, workflow'u çağıranından almaya geçin; tip artık mevcut değil.

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

vNext Runtime Platform Team

Breaking Changes​

1. StartTask/DirectTriggerTask sync varsayılanı true'dan false'a düştü​

Etkilenen Alan: Trigger-family task'lar — StartTask, DirectTriggerTask (TriggerSync) (vnext #917)

Önceki Davranış: Trigger bildirimleri varsayılan olarak senkron çalışıyordu — çağıran transition, hedef instance'ın pipeline'ı bitene kadar bloklanıyordu.

Yeni Davranış: sync varsayılanı false oldu; trigger bildirimleri varsayılan olarak enqueue edilir ve hedef pipeline'ı beklemeden döner. Eski senkron davranış açıkça "sync": true set edilerek korunabilir. Yön: davranış değişikliği.

Migration: Hedef instance'ın işini bitirmesine (örn. dönen veriye) senkron olarak bağımlı olan StartTask/DirectTriggerTask tanımlarını tarayın ve "sync": true ekleyin; aksi halde bu task'lar artık hedefin tamamlanmasını beklemeden devam eder.

2. ClickHouse entegrasyonu kaldırıldı​

Etkilenen Alan: DataSink — ClickHouse config/model/sink'leri (vnext #911)

Önceki Davranış: Runtime, hiçbir ortamda deploy edilmemiş ve her yerde disabled olan bir ClickHouse entegrasyonu (async-void flush timer'lı) taşıyordu; ilgili appsettings bölümleri mevcuttu.

Yeni Davranış: ClickHouse'a özgü kod, appsettings bölümleri ve DI wiring'i tamamen kaldırıldı. Generic DataSink extension point'i (IDataSinkManager/registry/hosted service) korunuyor, böylece gelecekteki bir analytics sink'i write path'lerine dokunmadan eklenebilir. Yön: daha kısıtlayıcı.

Migration: appsettings'inizde bir ClickHouse bölümü varsa kaldırın — artık okunmuyor. ClickHouse'a veri akıtan bir entegrasyon varsa (deploy edilmiş olması beklenmiyordu), yeni bir IDataSinkManager implementasyonu yazın.

3. Trace/metric console exporter'ları artık varsayılan olarak kapalı​

Etkilenen Alan: Execution ve Orchestration host telemetry config'i (vnext #911)

Önceki Davranış: Trace ve metric console exporter'ları production override'ı olmadan açık kalıyordu (logging console exporter'ı zaten yalnızca worker'larda açıktı).

Yeni Davranış: Execution ve Orchestration host'larının appsettings.json'ında trace/metric console exporter'ları kapatıldı; OTLP export değişmedi, logging console exporter'ı açık kalmaya devam ediyor. Yön: daha kısıtlayıcı.

Migration: Konsol çıktısındaki trace/metric satırlarına dayanan lokal debug/log toplama akışlarınız varsa, appsettings'te ilgili exporter'ı açıkça yeniden etkinleştirin.

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

vNext Runtime Platform Team

Breaking Changes​

1. Script metriklerinde hit/miss ayrımı ve gerçek execution metrikleri eklendi​

Etkilenen Alan: Prometheus script_* metrikleri (vnext #907)

Önceki Davranış: script_executions_total her zaman compile yolunda artıyordu (cache hit'ler dahil), gerçek script execution'ını yansıtmıyordu; compile ve execution latency'si ayrıştırılamıyordu.

Yeni Davranış: script_compilations_total{result=hit|miss,status} yeni metriği hit/miss'i ayırır; script_execution_duration_seconds{script_type,language,status} ve script_runtime_errors_total{script_type,language,error_type} gerçek execution funnel'larında (task-input, task-output, condition, transition-mapping, function) kaydedilir; script_compilation_duration_seconds yeni bir cache etiketi kazandı. script_executions_total değişmeden yayınlanmaya devam ediyor. Yön: davranış değişikliği.

Migration: Compile-rate panellerini rate(script_compilations_total[5m])'e, temiz compile latency'sini {cache="miss"} filtresine, gerçek execution sayacını script_execution_duration_seconds_count'a taşıyın. Acil aksiyon gerekmez — eski metrik hâlâ yayınlanıyor (bkz. madde 9).

2. Task audit request artık tam task tanımı yerine referans taşıyor​

Etkilenen Alan: InstanceTask.Request (transition/task audit kaydı) (vnext #907)

Önceki Davranış: Her execution'da InstanceTask.Request, mapping script kodu dahil tüm task tanımını gömüyordu.

Yeni Davranış: Request.task artık { key, version, domain, flow, type } referansını taşır; tanımın kendisi component store'da yaşamaya devam eder. InputResponse değişmedi. Yön: daha kısıtlayıcı.

Migration: request.task.* altında tanım alanlarını (config, mapping kodu gibi) parse eden harici tüketiciler varsa, gömülü referansı kullanarak tanımı component store'dan çözümlemeye geçin.

3. Instance data okumaları artık data versiyonu başına tek bir materialize edilmiş ağacı paylaşıyor​

Etkilenen Alan: scriptContext.instance.data (vnext #907)

Önceki Davranış: context.Instance.Data her erişimde taze bir dynamic tree materialize ediyordu; script tarafındaki mutasyonlar bir sonraki okumada sessizce kayboluyordu.

Yeni Davranış: Okumalar artık data versiyonu başına memoize edilir — bir mutasyon aynı transition içindeki sonraki okumalarda görünür olur (hâlâ persist edilmez; kalıcılık yalnızca ScriptResponse.Data üzerinden delta-only'dir). Benzer şekilde, parallel-branch task response değerleri artık parent ile branch arasında referans olarak paylaşılır (container'lar izole kalır); branch içinde var olan bir response değerinin yerinde mutasyonu, join sonrası parent'ta görünür olur. Yön: davranış değişikliği.

Migration: Script'ler context.Instance.Data'yı veya var olan task response değerlerini yerinde mutate edip eski "sessiz kayıp" davranışına güvenmemeli; değişiklikleri dokümante edildiği gibi ScriptResponse.Data üzerinden delta olarak döndürmeli.

4. SetBody, ExpandoObject/list anahtarlarını yazıldığı gibi koruyor​

Etkilenen Alan: scriptContext.setBody (ve WithBody builder yolu) (vnext #907)

Önceki Davranış: Bir ExpandoObject/List girişiyle SetBody, dictionary anahtarlarını global seçeneklerle serialize ediyordu; bu seçeneklerin DictionaryKeyPolicy'si anahtarları camelCase'e çeviriyordu.

Yeni Davranış: ExpandoObject/List girişi artık yapısal olarak klonlanır ve dictionary anahtarları yazıldığı gibi korunur. Anonymous-object/POCO girişleri değişmeden camelCase kalır. Bu, SetBody'yi (hiçbir zaman dict anahtarlarını camelCase yapmayan) SetStandardResponse ile ve instance-data ağaçlarıyla (persist anında camelCase) hizalar. Yön: davranış değişikliği.

Migration: SetBody'ye PascalCase expando anahtarları verip global ayarların camelCase yapmasına güvenen script'ler, kendi anahtarlarını kendileri camelCase yapmalı.

5. Parallel-branch merge conflict tespiti artık yapısal ve sıradan bağımsız​

Etkilenen Alan: scriptContext.mergeParallelBranch (vnext #907)

Önceki Davranış: Merge conflict tespiti serialize edilmiş metin karşılaştırmasına dayanıyordu ve sıraya duyarlıydı; aynı içeriğin farklı sırada gelen çıktısı sahte bir conflict fırlatıyordu.

Yeni Davranış: Karşılaştırma artık JsonElement.DeepEquals ile yapısal olarak yapılır (object property sırası göz ardı edilir); aynı içerik farklı sırada artık merge edilir. Yön: daha permissive.

Migration: Aksiyon gerekmez — gerçekten farklı içerik için conflict semantiği değişmedi.

6. Kendine referans veren script değerleri artık sessizce budanmak yerine hata fırlatıyor​

Etkilenen Alan: scriptContext.setBody — body/branch clone yolu (vnext #907)

Önceki Davranış: Body/branch clone JSON round-trip ile yapılıyordu (ReferenceHandler.IgnoreCycles); bir script bir ExpandoObject'i kendi içine (doğrudan veya transitif olarak) atadığında, tekrarlanan referans sessizce null'a çevriliyor ve task budanmış veriyle devam ediyordu.

Yeni Davranış: Clone artık yapısaldır ve aşırı nesting'i tespit ederek 256 derinlikte InvalidOperationException fırlatır; task normal error boundary üzerinden görünür şekilde fail olur. JSON'dan türeyen acyclic değerler etkilenmez. Yön: daha kısıtlayıcı.

Migration: Script'ler kendine referans veren dynamic değer üretmemeli. Bir mapping meşru olarak 256 seviyeden derin nesting yapıyorsa düzleştirin; bir task bu mesajla fail etmeye başlarsa mapping'i kendi içine atanan bir değer için inceleyin.

7. Payload envelope algılaması key/tags/stage'i rezerve ediyor; validation hata alanları path oldu​

Etkilenen Alan: Payload-mode algılaması (JSON ve form-url-encoded) ve JSON schema validation hata detayları (vnext #906)

Önceki Davranış: Payload-mode algılaması tek bir case-sensitive attributes alanına bakıyordu; attributes içermeyen bir envelope free-form sayılıp bütün olarak sarmalanıyor, schema key/tags'i business payload'u yerine doğruluyordu. Ayrıca reddedilen bir payload bazen hiçbir alan adı taşımadan ("errors":{}) geri dönebiliyordu — evaluation ağacı flatten edilirken bir node'un kendi hataları, child detayı varsa siliniyordu.

Yeni Davranış: Envelope algılaması artık key/tags/stage/attributes alan setinin tamamına bakar (her biri bağımsız opsiyonel). Bir node hem kendi hatasını hem child detaylarını raporlar; geçersiz bir subtree asla boş listeye düşmez. Hata alan adları artık keyword ("required") değil, instance path'i (root, customer.ownerUserId) olarak döner. Free-form bir payload'un kendi alanları yalnızca key/tags/stage isimlerinden oluşuyorsa, bu bir envelope'tan ayırt edilemez ve x-vnext-payload-mode: raw header'ının gönderilmesi gerekir. Yön: davranış değişikliği.

Migration: Eski keyword-tabanlı ("required") hata alan adlarına dayanan client parsing'i instance path'lerine (root, customer.ownerUserId, ...) güncelleyin. Yalnızca key/tags/stage isimli alanlar taşıyan free-form bir payload gönderen entegrasyonlar x-vnext-payload-mode: raw header'ını eklemeli. Ayrıntı için vnext reposundaki docs/contracts/form-url-encoded-payloads.md ve docs/contracts/json-validation.md'e bakın.

8. Component generation-token memoization aktive edildi — ≤5 saniyelik pod-arası görünürlük penceresi​

Etkilenen Alan: Orchestration host component cache (ComponentCache:GenerationMemoSeconds) (vnext #898)

Önceki Davranış: Memoization mekanizması koddan vardı ama varsayılan değeri 0'dı (etkisizdi) — her generation-token okuması distributed cache'e (Redis/Dapr state) gidiyordu.

Yeni Davranış: Orchestration host'un appsettings.json'ında ComponentCache:GenerationMemoSeconds 5 saniyeye ayarlandı. Bu, publish yapan pod'un anında güncel kalmasını sağlarken, diğer pod'ların bir publish'i görmesi en fazla 5 saniye gecikebilir. Pinlenmiş full version'lar ve çalışan instance'lar etkilenmez. ComponentCache__GenerationMemoSeconds env var'ı ile ortam bazında override/disable edilebilir. Yön: davranış değişikliği.

Migration: CI/CD pipeline'ında son publish'ten sonra smoke test/cutover öncesi N + margin saniye bekleme kuralı ekleyin (rollback runbook'ları için de aynı pencere geçerli). Anlık görünürlük gereken ortamlarda değeri 0'a çekin. Ayrıntı için vnext reposundaki docs/runtime/component-cache-generation-memo.md'a bakın.

9. script_executions_total metriği deprecated edildi​

Etkilenen Alan: Prometheus script_executions_total (vnext-meta/deprecations.json)

Önceki Davranış: script_executions_total, tek "script execution sayacı" olarak dashboard/alert'lerde kullanılıyordu.

Yeni Davranış: Metrik deprecated olarak işaretlendi (geriye dönük uyumluluk için değişmeden yayınlanmaya devam ediyor) — yerini script_compilations_total (compile-or-fetch, result=hit|miss) ve script_execution_duration_seconds_count (gerçek execution) alıyor; gelecekteki bir sürümde kaldırılacak. Yön: davranış değişikliği.

Migration: Dashboard/alert'leri madde 1'deki yeni metriklere taşıyın; script_executions_total'a olan bağımlılığı planlı şekilde kaldırın.

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

vNext Runtime Platform Team

Breaking Changes​

1. Geçersiz filter artık 400 ile reddediliyor​

Etkilenen Alan: Instance list/filter sorguları — Orchestration ve Monitoring (vnext #881)

Önceki Davranış: Desteklenmeyen bir operatör (gte, lte, neq, contains, ...), bozuk/kesik JSON veya yanlış yazılmış bir envelope anahtarı (fitler) sessizce yok sayılıyor, ilgili koşul hiç uygulanmadan sorgu tüm satırları döndürüyordu.

Yeni Davranış: Bu durumların tamamı 400 Validation:900011 ile (filter.unknownOperator, filter.unrecognizedFormat, filter.unknownProperty, filter.noOperator, filter.emptyLogicalOperator, filter.legacyNotAggregatable gibi alt kodlarla) reddedilir; bilinen yazım hataları için düzeltme önerisi de döner (gte → ge gibi). Boş filtre ({}, {"attributes":{}}) hâlâ "kısıtlama yok" anlamına gelir. Yön: daha kısıtlayıcı.

Migration: gte/lte/neq/contains gibi vocabulary-dışı operatörleri desteklenen wire operatörlerine çevirin (ge, le, ne, like/match). Bu operatörlerin daha önce geniş sonuç döndürdüğünü unutmayın — onlara dayanan rapor/ekranlarda sayılar yanlış olabilir.

2. Geçersiz sort/orderBy artık 400 ile reddediliyor​

Etkilenen Alan: Instance list sıralaması — Orchestration ve Monitoring (vnext #881)

Önceki Davranış: sort=-createdAt gibi bir kısayol, yanlış direction değeri, bilinmeyen alan adı veya güvensiz attributes. path'i sessizce yok sayılıyor, sorgu CreatedAt DESC'e düşüyordu.

Yeni Davranış: Tüm bu durumlar 400 Validation:900012 ile (sort.invalidJson, sort.invalidDirection, sort.unknownField, sort.unsafePath) reddedilir. sort/orderBy her zaman JSON formatı gerektirir: sort={"field":"createdAt","direction":"desc"}. Yön: daha kısıtlayıcı.

Migration: -field kısayolunu kullanan tüm client/entegrasyonları JSON forma taşıyın. Erişim loglarını sort=/orderBy= için tarayıp { (URL-encoded %7B) ile başlamayan değerleri düzeltin.

3. groupBy/aggregation doğrulaması ve legacy filtre + aggregation kombinasyonu reddi​

Etkilenen Alan: Instance query aggregation/groupBy — Orchestration ve Monitoring (vnext #881)

Önceki Davranış: Legacy (field=operator:value) formatta bir filtre groupBy/aggregation ile birlikte kullanıldığında GraphQL parser'a olduğu gibi veriliyor, koşul sessizce üretilmiyor ve aggregation filtresiz çalışıyordu; boş/bozuk aggregation JSON'u da benzer şekilde yok sayılıyordu.

Yeni Davranış: Legacy format + aggregation kombinasyonu 400 Validation:900011 (filter.legacyNotAggregatable) ile reddedilir; geçersiz groupBy/aggregation JSON'u sırasıyla 400 Validation:900013 / Validation:900014 döner. Yön: daha kısıtlayıcı.

Migration: Grouping/aggregation kullanan sorgularda filtreyi GraphQL-tarzı JSON olarak yazın; legacy field=operator:value sözdizimini bırakın.

4. GetInstancesTask'ta "-field" sort kısayolu artık reddediliyor; geçersiz filtre task'ı fail ediyor​

Etkilenen Alan: GetInstancesTask workflow task'ı — local ve remote (Dapr) yürütme (vnext #881)

Önceki Davranış: Task tanımındaki sort/filter çalıştırmadan önce doğrulanmıyordu; "sort": "-CreatedAt" dokümante edilmiş bir kısayol gibi görünse de hiçbir zaman çalışmıyordu — ParseOrderBy null dönüyor ve sorgu CreatedAt DESC'e düşüyordu. Geçersiz bir filter de task'ı sessizce filtresiz çalıştırıyordu.

Yeni Davranış: Task'ın filter ve sort alanları çalıştırmadan önce doğrulanır; geçersiz bir değer Result.Fail döner ve error boundary zincirine girer — bir Abort kuralı altında instance Faulted olabilir. Bu, önceden çalışan ve deploy edilmiş tanımların, kod değişikliği olmadan yalnızca runtime upgrade'i ile durabileceği anlamına gelir. Yön: daha kısıtlayıcı.

Migration: "sort": "-CreatedAt" değerini "sort": "{\"field\":\"createdAt\",\"direction\":\"desc\"}" gibi JSON forma geçirin (ayrıntılı eşleme tablosu için vnext reposundaki docs/contracts/instance-query-validation-breaking-changes.md'e bakın). Runtime upgrade'inden önce domain paketlerinizi "sort" alanı { ile başlamayan tüm GetInstancesTask tanımları için tarayın ve redeploy edin.

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

vNext Runtime Platform Team

Breaking Changes​

1. updateData artık state'in OnEntry/OnExit'ini tekrar çalıştırmıyor, timer'ları yeniden kurmuyor​

Etkilenen Alan: Transition pipeline — $self hedefli transition'lar (migrations.json: self-target-transitions-skip-state-lifecycle) (vnext #883, vnext #884)

Önceki Davranış: updateData (hedefi her zaman $selfe sabitlenmiş) tüm pipeline'ı çalıştırıyordu: mevcut state'in OnExit task'ları çalışıyor, aynı state'in OnEntry task'ları ikinci kez çalışıyor ve state'in scheduled transition'ları iptal edilip sıfırdan yeniden kuruluyordu — her timeout sessizce sıfırlanıyordu.

Yeni Davranış: updateData için CancelScheduledJobs (39), OnExit (40), OnEntry (60) ve Schedule (80) adımları hariç tutulur. Transition'ın kendi onExecutionTasks'i, data yazımı ve auto-transition değerlendirmesi değişmeden çalışır; state hiç terk edilmediği/girilmediği için lifecycle hook'ları tekrar tetiklenmez. Yalnızca gerçek updateData transition'ını etkiler — $self hedefli shared transition'lar (ve literal self-loop'lar) tam lifecycle'ı çalıştırmaya devam eder. Yön: davranış değişikliği.

Migration: updateData'nın state'in OnEntry'sini tekrar çalıştırmasına dayanan domain'ler bu mantığı transition'ın kendi onExecutionTasks'ine taşımalı. updateData'nın scheduled-transition timer'ını sıfırlamasına dayanan akışlar resetlemeyi kendileri modellemeli. Domain tanımlarında "target": "$self" için grep atmak faydalı olur.

2. cancel/exit/timeout artık Busy'yi pipeline yerine accept anında set ediyor​

Etkilenen Alan: Transition admission / Busy durumu (vnext #884)

Önceki Davranış: cancel/exit/timeout transition'ları Busy 409 kontrolünden muaftı ve Busy bayrağı pipeline içinde set ediliyordu; bu transition'lar admission sırasında ayrı bir kilit almıyordu.

Yeni Davranış: cancel/exit/timeout artık Busy'yi accept anında, diğer tüm transition kind'leriyle aynı tek kilit altında set eder; iş IsPreReserved olarak pipeline'a girer ve pipeline ikinci kez kilit almaz. Sonuç: bir client'ın instance'ı Busy olarak gözlemlediği an daha erken kayar. Yön: davranış değişikliği.

Migration: Busy durumunu 202 yanıtından hemen sonra kontrol eden client/monitoring akışları, bu durumu artık daha erken görebileceğini hesaba katmalı; timing'e dayanan test veya izleme senaryolarını gözden geçirin.

3. Task binding'lerinde reserved trace/correlation header'ları artık ezilemiyor​

Etkilenen Alan: Outbound task header binding'leri — HTTP, SOAP, Dapr service/binding/pub-sub/trigger invoker'ları (vnext #879, vnext #882)

Önceki Davranış: Bir task binding'i (mapping/config) traceparent, tracestate, baggage, x-request-id, X-Correlation-Id veya X-Workflow-Instance-Id header'larını kendi değerleriyle set edebiliyordu; bu, correlation zincirini kopartabiliyor veya sahte bir correlation ID'yi taşıyabiliyordu.

Yeni Davranış: Bu altı header reserved kabul edilir (IsReservedTraceHeader) — mapping'de tanımlı değerleri kaldırılır ve yalnızca doğrulanmış activity baggage'ından gelen değerlerle yeniden yazılır. Kimlik claim'leri (sub, act_sub) reserved değildir ve yalnızca fill-if-absent kuralına tabidir — binding bunları set ederse o değer kazanır. Yön: daha kısıtlayıcı.

Migration: Task tanımlarında bu altı header'ı elle set eden mapping'leri tarayın; artık hiçbir etkisi olmayacak. Correlation zincirini taşımak için bu değerlere ihtiyaç varsa, header yerine platformun otomatik yaydığı context'e güvenin.

4. Log enricher alan adları RequestHeader. prefix'i olmadan geliyor​

Etkilenen Alan: Structured logging enricher alanları (Aether ≥ 1.0.35) (vnext #882)

Önceki Davranış: sub / act_sub gibi identity claim'leri log kayıtlarında requestheader_act_sub gibi prefix'li ve backend'e göre düzleştirilmiş adlarla görünüyordu.

Yeni Davranış: LoggingEnricherOptions:RequestHeaderKeyPrefix her host'ta "" olarak ayarlandı; alanlar artık sub, act_sub, jti, role, x_parent_instance_id, user_agent gibi prefix'siz adlarla yazılıyor. Response header'ları için prefix varsayılanda kalır. Yön: davranış değişikliği.

Migration: requestheader_act_sub gibi eski alan adlarına dayanan Kibana/Elastic dashboard'larını ve saved query'lerini yeni prefix'siz adlara (act_sub, sub, …) güncelleyin. Bu değişiklik Aether ≥ 1.0.35 gerektirir.

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

vNext Runtime Platform Team

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