This release consolidates seven interim versions (v0.0.44 through v0.0.49) into the stable v0.0.50 release. The primary themes are pipeline correctness, infrastructure resilience, performance optimization, and observability.

On the correctness front, workflow timeout now executes the full TransitionPipeline (onExit, onEntry, automatic transitions, finish handling) instead of a direct state mutation, and the async execution race condition that prematurely set instances to Active before post-commit jobs completed has been resolved. Extension error handling is reclassified so that infrastructure failures abort the request while application-level errors degrade gracefully. Schema validation is now enforced on sync=false requests, preventing invalid payloads from being accepted and later faulting.

Infrastructure improvements include UTC DateTime normalization via an EF Core interceptor and global ValueConverter (independent of PostgreSQL server timezone), a PgBouncer-safe schema command interceptor replacing the connection-level interceptor, and a timestamp with time zone migration for SubFlowStateChangedAt. On the CI/CD side, software supply chain security (Cosign signing, provenance attestation) and a cross-repo dispatch token fix strengthen the delivery pipeline.

Performance gains come from distributed cache tracing with short-TTL local vidx caching (eliminating redundant Redis roundtrips), broadcast cache invalidation that reads from distributed cache instead of performing a full DB reload on non-initiating pods, and hot-path index adjustments that fix a GetInstanceHistory regression and remove a redundant partial PK index.

New capabilities include dynamic workflow timeout mapping via ITimerMapping scripts (with static duration fallback), ErrorBoundary enrichment with errorMessage, errorState, and errorTask parameters in instance data, acceptedStatusCodes on HTTP-based task types to suppress ErrorBoundary for expected non-2xx responses, and local/remote metadata parity for GetInstances and GetInstanceData task executors.

Bug Fixes​

Timeout target state pipeline not executed (#514)​

When a workflow instance timed out, FlowTimeoutJobHandler changed the instance state and marked it complete but never ran the TransitionPipeline. All onExit tasks, onEntry tasks, automatic transitions, scheduled transitions, and finish-state handling were silently skipped. The handler now invokes the full TransitionPipeline with a synthetic timeout transition context, ensuring consistent state lifecycle execution regardless of how a transition is triggered.

Reference: #514

Extension failures abort the entire request (#515)​

On all InstanceData read endpoints, any extension task failure caused the entire HTTP response to be aborted — even when the extension's outputMapping had already handled the downstream error at the application level. Error classification is now split into two categories:

• Infrastructure errors (network timeout, DNS failure, connection refused) — fail-fast, abort request.
• Application-level / output-mapping-handled errors — degrade gracefully, continue with remaining extensions.

Reference: #515

UTC DateTime normalization (#520)​

PostgreSQL server configured with TimeZone = 'Europe/Istanbul' caused silent +3h offset corruption on all DateTime values stored in timestamp (without time zone) columns. A two-layer defense-in-depth fix was implemented:

1. Write path: UtcDateTimeInterceptor (SaveChangesInterceptor) normalizes all DateTime properties to UTC before SaveChanges.
2. Read path: Global UtcDateTimeConverter via ConfigureConventions ensures all DateTime values read from the database are tagged as DateTimeKind.Utc.

Behavior is now independent of the PostgreSQL server timezone configuration.

Reference: #520

SubFlowStateChangedAt timestamp migration (#525)​

The SubFlowStateChangedAt column in InstancesCorrelations was timestamp without time zone. A migration converts it to timestamp with time zone using AT TIME ZONE 'UTC', aligning it with the rest of the schema.

Reference: #525

PgBouncer-safe schema interceptor (#534)​

NpgsqlSchemaConnectionInterceptor set search_path at connection open time, which PgBouncer transaction-mode pooling could reassign to a different session. The new PgBouncerSafeSchemaCommandInterceptor prepends SET search_path inline to every SQL command, eliminating the extra round-trip and ensuring schema consistency under pooled connections.

Reference: #534

Async mode race condition: premature Active status (#535)​

When sync=false, ResolveAvailableStep and ClearBusyOnResumeStep wrote Active status to the database mid-pipeline, before post-commit jobs (SubFlow start, remote task invocations) had completed. Clients polling during this window would see Active while the pipeline was still executing. The status update is now deferred via PipelineDirectives.SetResolvedStatus and applied in TransitionPipeline.ApplyResolvedStatusAsync only after all post-commit jobs complete.

Reference: #535

Cross-repo dispatch token scope (#541)​

The actions/create-github-app-token step generated a token scoped only to vnext. peter-evans/repository-dispatch targeting vnext-helm-charts failed with HTTP 403. The token scope now includes both repositories.

Reference: #541

Schema validation skipped on sync=false (#556)​

When sync=false, the async strategy accepted any payload without validating against the transition's JSON schema. Invalid data entered the system and faulted during background execution. Schema validation is now performed before accepting the request, regardless of the sync flag. Invalid payloads return 400 Bad Request with field-level errors.

Reference: #556

Local execution metadata parity for GetInstances / GetInstanceData (#563)​

GetInstanceDataTaskExecutor.ExecuteLocalAsync returned no metadata on the happy path, and GetInstancesTaskExecutor had inconsistent metadata between local and remote paths. Both executors now build and return the same metadata dictionary as the remote/grouped paths, ensuring downstream consumers (scripting, mapping, logging) see identical shapes regardless of execution mode.

Reference: #563

Features & Enhancements​

ErrorBoundary enrichment: error message, state, task parameters (#496)​

ErrorBoundary now populates errorMessage, errorState, and errorTask fields in instance data when an error is caught. This enables downstream consumers (backoffice UIs, mapping scripts) to display meaningful error context and handle errors programmatically.

Reference: #496

Dynamic timeout mapping for subprocesses (#524)​

Workflow-level timeout now supports an optional mapping field (a ScriptCode object implementing ITimerMapping) for dynamic timeout duration calculation at runtime. When the mapping script succeeds, its TimerSchedule result is used. On failure, the static timer.duration is used as fallback. A static timer configuration is required when mapping is defined (validation enforced).

Definition example:

"timeout": {
  "key": "$timeout",
  "target": "timed-out",
  "versionStrategy": "None",
  "timer": { "reset": "false", "duration": "PT1H" },
  "mapping": {
    "location": "./src/TimeoutMapping.csx",
    "code": "<BASE64>"
  }
}

Use case: A parent workflow starts a subprocess with timeoutMinutes: 30 in the body. The subprocess timeout mapping reads this value and schedules a 30-minute timeout. If the mapping fails, the static 1-hour fallback applies.

Documentation: Transitions, Workflow Definition

Reference: #524

Task acceptedStatusCodes configuration (v0.0.50+)​

HTTP-based task types now support an optional acceptedStatusCodes array in their config section. Status codes listed here are treated as successful even when they are error codes (4xx, 5xx), preventing the ErrorBoundary from being triggered. Supports exact codes ("404"), wildcard patterns ("4xx"), and partial wildcards ("40x").

Supported task types: Dapr Service (3), HTTP (6), StartTask (11), DirectTriggerTask (12), GetInstanceDataTask (13), SubProcessTask (14), GetInstances (15).

"config": {
  "method": "GET",
  "url": "http://user-service/api/users/{userId}",
  "acceptedStatusCodes": ["404"]
}

Documentation: HTTP Task, Dapr Service Task, Trigger Tasks

Software supply chain security (#545)​

The CI/CD pipeline now produces verifiable, signed, and traceable container images:

• Digest-based image handling for immutable references
• Cosign keyless signing with GitHub OIDC for artifact authenticity
• Build provenance attestation via GitHub attestation actions
• Ready for downstream admission-policy verification

Reference: #545

Performance Improvements​

Broadcast cache invalidation: distributed-cache-first reload (#557)​

Non-initiating pods receiving a DefinitionCacheInvalidationEvent broadcast no longer perform a full paginated DB read of all active instance data. Instead, they read instance metadata (keys/versions), check the distributed cache first (which the initiating pod has already populated), and upsert only into the local in-memory cache. A per-key DB fallback handles distributed cache misses. This eliminates the heavy, redundant DB round-trip that stalled the first pod receiving the broadcast.

Reference: #557

Distributed cache tracing and Redis vidx optimization (#568)​

• Cache tracing: A new CacheActivityHelper (ActivitySource("BBT.Workflow.Cache")) wraps distributed cache operations (Cache.Get, Cache.Set, Cache.Remove, Cache.Warmup, Cache.VersionIndex) with proper parent spans so Dapr sidecar spans nest correctly in trace tools.
• vidx short-TTL local cache: CacheSet now caches Redis version-index (vidx) query results in a ConcurrentDictionary with a short TTL, eliminating 3–5+ redundant Redis roundtrips per transition hop. The local cache is invalidated on SetAsync and InvalidateAsync.

Reference: #568

Hot-path index adjustments and GetInstanceHistory fix (#561)​

• Dropped redundant IX_Instances_Active_Id partial PK index (never used by the planner, only write overhead).
• Added non-partial IX_Instances_Key B-tree for FindByIdentifierAsync key-based lookups across all statuses.
• Fixed GetInstanceHistory regression: a new FindByIdentifierWithFullHistoryAsync repository method loads the full DataList without the IsLatest filter, restoring complete revision history on the history endpoint.

Reference: #561

Breaking Changes​

None for this release.

Configuration Updates​

Configuration for v0.0.50:

{
  "runtimeVersion": "0.0.50",
  "schemaVersion": "0.0.41"
}

Note: Schema package 0.0.50 is the documented pairing with this runtime. The task-definition.schema.json and workflow-definition.schema.json include new fields (acceptedStatusCodes, timeout.mapping). Update domain validate.js / Ajv2019 usage per Schema Management.

Issues Referenced​

• vnext #496 — ErrorBoundary enrichment (error message, state, task)
• vnext #514 — FlowTimeoutJobHandler pipeline execution
• vnext #515 — Extension error classification / graceful degradation
• vnext #520 — UTC DateTime normalization
• vnext #521 — Rejecting out-of-order SubFlow state (duplicate of #520/#525)
• vnext #524 — Dynamic timeout mapping for subprocesses
• vnext #525 — SubFlowStateChangedAt timestamptz migration
• vnext #534 — PgBouncer-safe schema interceptor
• vnext #535 — Async mode race condition (premature Active status)
• vnext #541 — Cross-repo dispatch token scope
• vnext #545 — Software supply chain security
• vnext #556 — Schema validation on sync=false
• vnext #557 — Broadcast cache invalidation optimization
• vnext #561 — Hot-path indexes + GetInstanceHistory fix
• vnext #563 — Local execution metadata parity
• vnext #568 — Distributed cache tracing + vidx optimization

Summary​

• Timeout pipeline now executes full TransitionPipeline (onExit, onEntry, automatic transitions, finish handling) instead of direct state mutation.
• Extension error handling reclassified: infrastructure errors fail-fast, application-level errors degrade gracefully.
• UTC DateTime normalization via EF Core interceptor + global ValueConverter, independent of server timezone.
• PgBouncer-safe schema command interceptor replaces connection-level interceptor.
• Async race condition fixed: Active status deferred until all post-commit jobs complete.
• Schema validation enforced on sync=false requests; invalid payloads rejected with 400.
• Dynamic timeout mapping via ITimerMapping scripts with static duration fallback.
• ErrorBoundary enrichment with errorMessage, errorState, errorTask in instance data.
• acceptedStatusCodes on HTTP-based tasks to suppress ErrorBoundary for expected non-2xx responses.
• Supply chain security: Cosign signing, provenance attestation, digest-based image handling.
• Cache performance: distributed-cache-first broadcast reload, vidx short-TTL local cache, cache operation tracing.
• Index optimization: redundant partial PK dropped, Key index added, GetInstanceHistory regression fixed.
• Metadata parity between local and remote execution paths for GetInstances/GetInstanceData task executors.

vNext Runtime Platform Team April 25, 2026

This release improves reliability and consistency across flows, tasks, and domain events: cancel transitions on single-flow definitions validate correctly, TriggerTask family tasks map HTTP status codes on local execution for errorBoundary matching, and AmbientServiceProvider scopes restore domain event delivery (including effective-state and subflow completion paths). GetInstance / GetInstanceData honor the version query parameter, GroupBy and aggregation work when filters reference Instance table columns, DaprServiceTask runs without invalid trace context for non-flow functions, and definition cache warm-up no longer loads the full active-instance set into memory (OutOfMemoryException fix). New capabilities include auto-transition rules evaluated with Dynamic Expresso over instance JSONB, and instance-data–based authorization using $user, $role, and $userBehalfOf JSONPath-style selectors plus $InstanceBehalfOfStarter and $PreviousBehalfOfUser.

Bug Fixes​

Flow-level cancel transition validation (#509)​

The well-known cancel transition key resolved correctly but failed StateTransitionListSpecification validation (Transition:100020) on single-flow workflows. Validation now accepts the cancel definition as intended.

Reference: #509

DaprServiceTask: trace context without flow instance (#507)​

DaprServiceTask could produce an invalid trace context when function executions ran without a workflow instance. Execution is corrected for this scenario.

Reference: #507

AmbientServiceProvider in Gateway and PostCommit scopes (#504)​

AmbientServiceProvider.Current is restored consistently across local Gateway and PostCommit scopes, preventing domain event loss and related hook gaps. Effective state and subflow completion events are stabilized on this path.

Reference: #504

GroupBy / aggregation with Instance column filters (#488)​

Aggregations using GroupBy failed when the filter referenced Instance metadata columns alongside instance data filters. Query generation is fixed for this combination.

Reference: #488

TriggerTask family: StatusCode on local execution (#493)​

TriggerTask-family tasks did not map HTTP StatusCode on local execution, so errorBoundary matching against standard codes (e.g. 409, 404) was unreliable. Local execution now aligns with the result pattern and error-boundary expectations.

Reference: #493

GetInstance / GetInstanceData: version query parameter (#490)​

The version query parameter was ignored on GetInstance and GetInstanceData; operations now respect instance version as intended for consistency.

Reference: #490

Definition cache invalidation: memory use (#487)​

Full active-instance loads during definition cache warm-up could cause OutOfMemoryException. Initialization uses a revised approach that avoids loading the entire active-instance table into memory.

Reference: #487

Features​

Auto-transition rules with Dynamic Expresso over instance data (#470)​

Automatic transition Rule evaluation can use Dynamic Expresso for plain-text boolean expressions over instance JSON and ScriptContext, as an optional alternative to Roslyn IConditionMapping scripts.

How to select Expresso vs Roslyn

• Set rule.location to dynamicExpresso, put the expression in rule.code, and use native encoding: "encoding": "NAT" in JSON (or ScriptCode.FromNative in code).
• Any other location keeps the Roslyn path (RoutingConditionEvaluator → ScriptConditionEvaluator).

context parameter (ExpressoRuleContext)

Expressions take a single context argument built from ScriptContext with an allowlist, including: Body, CurrentTransition (e.g. Data / Header), MetaData, Workflow, Instance (including Data as JSON), Headers, QueryParameters, RouteValues, Transition (key/from/target/trigger fields; no embedded rule/timer/task payloads), and Runtime. Some members may be null when not present on the context.

JSON access

Instance.Data, Body, and related JSON are surfaced as RuleJsonDynamic (dynamic members, indexers, array Count / Contains). Missing keys resolve to null. Prefer AsDouble() / AsInt32(), AsBoolean(), AsArrayLength(), and array Contains as needed.

Expression samples

context.Instance.Data["amount"].AsDouble() > 100000
context.Instance.Data["documents"].AsArrayLength() == 0
context.Body["score"].AsDouble() >= 80
context.Transition != null && context.Transition.Key == "approve-auto"

Definition fragment (NAT)

"rule": {
  "location": "dynamicExpresso",
  "encoding": "NAT",
  "code": "context.Instance.Data.absenceType.ToString() == \"personal-leave\""
}

Full detail, ExpressoRuleContext member table, and additional examples: Mappings — subsection Rule expressions with Dynamic Expresso (v0.0.43+).

Reference: #470

Instance-data authorization: $user / $role / $userBehalfOf JSONPath (#469)​

Authorization is extended to compare token values to data resolved from ScriptContext (including instance data) via JSONPath-style expressions:

Additional system roles:

This applies across available transition and data authorization (including Master schema field visibility where supported).

Documentation: Function APIs — Authorization (subsection Instance-data JSONPath authorization (v0.0.43+)).

Reference: #469

Breaking Changes​

None for this release.

Configuration Updates​

Configuration for v0.0.43:

{
  "runtimeVersion": "0.0.43",
  "schemaVersion": "0.0.39"
}

Note: Schema package 0.0.39 remains the documented pairing with this runtime (same as v0.0.42). Update domain validate.js / Ajv2019 usage per Schema Management if you have not already.

Issues Referenced​

• vnext #509 — Cancel transition validation (single-flow)
• vnext #507 — DaprServiceTask trace context without instance
• vnext #504 — AmbientServiceProvider / domain events
• vnext #488 — GroupBy + Instance filters
• vnext #493 — TriggerTask StatusCode / errorBoundary
• vnext #490 — GetInstance(GetInstanceData) version query
• vnext #487 — Definition cache OOM
• vnext #470 — Dynamic Expresso auto-transition rules
• vnext #469 — Instance JSONPath authorization

Summary​

• Cancel transition validation fixed for single-flow definitions.
• Stable domain events and hooks via AmbientServiceProvider scope fixes; effective state / subflow completion paths improved.
• GetInstance / GetInstanceData respect version; GroupBy with Instance filters fixed; DaprServiceTask without instance fixed; TriggerTask StatusCode for errorBoundary on local runs.
• Memory-safe definition cache warm-up (no full active-instance table load).
• Dynamic Expresso for auto-transition rules over instance data; JSONPath-style $user / $role / $userBehalfOf authorization and new behalf-of system roles.

vNext Runtime Platform Team
April 6, 2026

This release shifts flow database schema creation and migration to deploy time via a DB-Migrator job instead of running migration checks on every start and transition request. It improves observability with consistent structured logging and TaskCoordinator span tracing (Aether). For synchronous start and transition calls (sync=true), responses now include mapped instance data (attributes, ETags, extensions) in addition to id and status. User-defined functions support multi-task execution with ordered onExecutionTasks and optional output mapping via IOutputHandler. SubFlow definitions can use an overrides object to replace transition roles, state query roles, timeouts, and related behavior while keeping legacy view override compatibility. ScriptBase adds collection and dynamic-object helpers (CreateObject, GetList, ListFilter, ListSelect, and related APIs) for safer in-script shaping of Instance.Data. AutoMapper has been replaced by Mapperly in the Aether SDK, and AutoMapper is no longer a vNext dependency.

Bug Fixes​

Instance state during subflow completion propagation (#461)​

While a subflow completion was still propagating, the parent instance could incorrectly report Completed status. The State function (long polling) was adjusted so parent status reflects the correct phase during that window.

Reference: #461

Schema: flowVersion and config required (#88, #89)​

flowVersion is required across definition schemas, and config is required on task definitions in vnext-schema, aligning validation with runtime and avoiding serialization issues.

References: #88, #89

Schema: errorBoundary abort action aligned with backend (#93)​

The workflow definition schema for errorBoundary (abort action / transition) was aligned with backend validators.

Reference: #93

Workflow CLI: correct .csx file when names collide (#10)​

When the same .csx file name existed in multiple component directories, the CLI could update the wrong file. Selection now respects the configured location (vnext-workflow-cli v1.0.6).

Reference: #10

Init service: timestamps in logs and clearer errors (#475)​

Init service logs include timestamps. Helm chart updates increase nginx ingress timeouts where init was timing out.

Reference: #475

Remote view / roles: headers, ViewType, init domain replacement, StateSubType (#482)​

HTTP handling for remote view and remote role calls was hardened (null-safety, ViewType enum, content-header forwarding). Remote view definitions receive corrected domain replacement in init. StateSubType adds Cancelled = 7 and Timeout = 8.

Reference: #482

Features​

Flow DB schema at deploy time (#449)​

Per-request migration checks on start and transition have been removed. A DB-Migrator job applies schema creation and migrations at deploy time.

Reference: #449

Telemetry: Aether logging and TaskCoordinator spans (#451)​

Logging is more consistent end-to-end, and task executions are easier to trace with span instrumentation on the task coordinator path.

Reference: #451

Synchronous start/transition: mapped instance payload (#393)​

When sync=true, start and transition responses can include key, attributes, eTag, entityEtag, extensions, and related instance envelope fields—not only id and status.

Reference: #393

SubFlow overrides for roles and timeouts (#405)​

Beyond legacy view overrides, subFlow.overrides supports transitions (e.g. role grants), states (e.g. queryRoles), timeout definitions, and other replace-mode overrides for authorize and transition list behavior.

Reference: #405

Mapperly replaces AutoMapper in Aether / vNext (#52)​

Mapperly is used in the Aether SDK; AutoMapper (commercial license) is no longer required for vNext.

Reference: #52

Multi-task functions and output mapping (#478)​

Function definitions may declare multiple onExecutionTasks (ordered). Each task can supply mapping; later tasks can consume earlier task outputs. Optional output mapping uses IOutputHandler to build the function’s final script response.

Reference: #478

ScriptBase: collection and dynamic-object helpers​

ScriptBase now includes helpers to work with dynamic objects and lists in mapping scripts—e.g. CreateObject, CreateList, SetProperty, GetList, AsList, ListAdd / ListRemove, ListFilter, ListCount, ListAny, ListFirst / ListLast, ListSelect<TResult>, RemoveProperty, and ToDictionary. These reduce fragile casts when reading or building structures under Instance.Data.

Documentation: Mapping Guide — ScriptBase (see Collection and dynamic object helpers). Runnable sample mappings: release/extra/script-base-usage/.

ETag strategy (authorization-aware) follow-up (#448)​

Work continues to keep etag / entityETag and response headers consistent when authorization changes the response shape (see also Release Notes v0.0.40).

Reference: #448

Breaking Changes​

1. GET /api/v1/{domain}/workflows/{workflow}/functions/{function} is removed. Integrations that called a workflow-level function by name must migrate to supported APIs (e.g. instance-scoped State, Data, View, Schema, or other documented endpoints).

2. GetInstancesTask (task type 15) now calls GET /api/v1/{domain}/workflows/{workflow}/instances (with query parameters for filter, paging, sort) instead of the previous workflow functions/data-style URL. Validate mapping scripts and consumers of task output against the new response shape.

3. Domain package validation (validate.js): Repositories using the shared validator must adopt Ajv2019 (JSON Schema draft 2019-09) so workflow definitions validate against updated schemas (including errorBoundary fixes). See internal release/extra/validate.js or your template’s migration notes for the full script changes.

Configuration Updates​

Configuration for v0.0.42:

{
  "runtimeVersion": "0.0.42",
  "schemaVersion": "0.0.39"
}

Note: Use schema package 0.0.39 with this runtime. Update validate.js and domain tooling accordingly.

Issues Referenced​

• vnext #461 — Subflow propagation / instance state
• vnext-schema #88 — flowVersion required
• vnext-schema #89 — Task config required
• vnext-schema #93 — errorBoundary schema alignment
• vnext-workflow-cli #10 — CSX selection by location
• vnext #475 — Init logs / ingress timeout
• vnext #482 — Remote view/roles, StateSubType 7–8
• vnext #449 — DB-Migrator / deploy-time schema
• vnext #451 — Telemetry / spans
• vnext #393 — Sync start/transition payload
• vnext #405 — SubFlow overrides
• aether #52 — Mapperly
• vnext #448 — ETag strategy
• vnext #478 — Multi-task functions / output mapping

Summary​

• Deploy-time database schema lifecycle via DB-Migrator; no per-request migration on start/transition.
• Better telemetry: structured logs and TaskCoordinator spans.
• sync=true start/transition returns full mapped instance fields where applicable.
• SubFlow overrides for roles, states, timeouts; multi-task functions with IOutputHandler output mapping.
• ScriptBase collection / dynamic-object helpers and samples under release/extra/script-base-usage/.
• Breaking: removed .../functions/{function}; GetInstancesTask uses .../instances; update validate.js for Ajv2019.

vNext Runtime Platform Team
March 25, 2026

This release improves schema consistency by making flowVersion required in definition schemas (vnext-schema) and config required in task definitions, and introduces an authorization-aware ETag strategy for data endpoints: response body exposes etag (request/response change) and entityETag (entity data change), with corresponding ETag and X-Entity-ETag response headers. It also fixes View function handling of deep JSON content (max depth increased to 256, ReferenceHandler.IgnoreCycles) and removes an unnecessary retry block in the cache invalidation handler.

Bug Fixes​

1. Make flowVersion a Required Field in Definition Schemas​

flowVersion is now required in definition schemas in vnext-schema. This aligns the schema with runtime behavior (flowVersion was already required in v0.0.39) and ensures consistency across tooling and validation.

Reference: #88 - Make flowVersion a required field in definition schemas

2. Make config a Required Field in Task Definitions​

Task definitions now require a config section. The task-definition schema (task-definition.schema.json) has been updated so that config is mandatory, ensuring all task definitions carry explicit configuration and improving consistency.

Reference: #89 - Make config a required field in task-definition.schema.json

Tasks / Improvements​

Redesign ETag Strategy for Authorization-Aware Responses​

After adding the authorization layer to data endpoints, response content could change per caller, and the previous ETag logic became inconsistent. The ETag strategy has been redesigned so that:

• etag in the response body reflects request/response change (e.g. authorization or response shape).
• entityETag in the response body reflects entity data change.

Clients can use entityETag to track when the underlying data has changed and etag for general response caching. The same values are exposed in response headers:

• ETag — matches the etag value (without surrounding quotes in the header).
• X-Entity-ETag — matches the entityETag value.

Example response body:

{
  "etag": "\"Hko5JI4fDcAOOnf-KGFNA7Xo_MpuxcLl1_hg5j2Sua8\"",
  "entityEtag": "\"01KK8Q8N5T6H49T8AENYT6Z6ZQ\""
}

Example response headers:

ETag: "Hko5JI4fDcAOOnf-KGFNA7Xo_MpuxcLl1_hg5j2Sua8"
X-Entity-ETag: "01KK8Q8N5T6H49T8AENYT6Z6ZQ"

Reference: #448 - Redesign ETag Strategy for Authorization-Aware Responses

Other​

View Function: Deep JSON Content and ReferenceHandler​

An error occurred when the content field of a view contained JSON deeper than the default maximum depth (32). The maximum depth has been increased to 256, and ReferenceHandler has been set to IgnoreCycles so that deeply nested or cyclic structures in view content are handled correctly.

Cache Invalidation Handler: Retry Behavior​

An unnecessary retry block in the cache invalidation handler was removed, so retries are no longer incorrectly prevented when appropriate.

Configuration Updates​

Configuration for v0.0.40:

{
  "runtimeVersion": "0.0.40",
  "schemaVersion": "0.0.38"
}

Note: Schema version 0.0.38 is used with this runtime version. Ensure your configuration and tooling reference the updated schema.

Issues Referenced​

• #88 - Make flowVersion a required field in definition schemas
• #89 - Make config a required field in task-definition.schema.json
• #448 - Redesign ETag Strategy for Authorization-Aware Responses

Summary​

With this release:

• Definition schemas (vnext-schema) require flowVersion; task definitions require config.
• Data endpoints use an authorization-aware ETag strategy: etag and entityETag in the response body, with ETag and X-Entity-ETag response headers for consistent caching and change detection.
• View function supports deeper JSON content (max depth 256) with ReferenceHandler.IgnoreCycles.
• Cache invalidation handler retry behavior is corrected.

vNext Runtime Platform Team
March 10, 2026

This release adds X-App-Version in response headers and the Health endpoint, AddHeader and RemoveHeader methods on HttpTask, DaprService, and Trigger-family tasks for fine-grained header control, and ParentInstanceId in trace and logging for cross-domain subflow correlation.

Features​

1. App Version in Responses​

API responses and the Health endpoint now include the application version in the X-App-Version response header. This allows clients and monitoring tools to identify the runtime version without parsing response bodies.

Where it appears:

• Response headers: All API responses include an X-App-Version header with the runtime version (e.g. 0.0.38).
• Health endpoint: The GET /health response also includes the X-App-Version header.

Example Health response headers:

HTTP/1.1 200 OK
Content-Type: application/json
X-App-Version: 0.0.38

Reference: #365 - App Version in Responses - Implementation

2. AddHeader and RemoveHeader on Tasks with Headers Support​

HttpTask, DaprServiceTask, and the Trigger task family (StartTask, DirectTriggerTask, GetInstanceDataTask, SubProcessTask) now support AddHeader and RemoveHeader methods in addition to SetHeaders. This allows mapping code to add or remove individual headers without replacing the entire header set.

Available methods (v0.0.38+):

• AddHeader(string name, string value): Adds or overwrites a single header.
• RemoveHeader(string name): Removes a header by name (case-insensitive where applicable).

Usage example (HttpTask):

var httpTask = task as HttpTask;
// Add or override a single header
httpTask.AddHeader("X-Correlation-ID", context.Instance.Data.correlationId);
httpTask.AddHeader("Authorization", "Bearer " + token);
// Remove a header
httpTask.RemoveHeader("X-Optional-Header");

Usage example (DirectTriggerTask):

var directTriggerTask = task as DirectTriggerTask;
directTriggerTask.SetInstance(context.Instance.Data.approvalInstanceId);
directTriggerTask.SetTransitionName("approve");
directTriggerTask.AddHeader("X-Request-Source", "parent-workflow");
directTriggerTask.AddHeader("X-Correlation-ID", context.Instance.Id);

Behavior:

• Headers defined in the task config (JSON) are applied first. AddHeader and RemoveHeader in mapping run afterward, so mapping can override or remove config headers.
• SetHeaders continues to replace the entire header set when called; use AddHeader/RemoveHeader when you need incremental changes.

Reference: #417 - feat(domain): Add AddHeader and RemoveHeader to tasks with Headers support

3. ParentInstanceId in Trace and Log Correlation (Cross-Domain Subflow)​

Trace and logging now include ParentInstanceId where applicable. When an instance is created or driven by a parent (e.g. subflow, cross-domain trigger), logs and trace metadata carry the parent instance id so you can correlate activity across the parent and child.

Benefits:

• Log correlation: Filter or search logs by parent instance id to see all activity for a given parent flow.
• Distributed tracing: Trace views can follow the relationship between parent and child instances across domains.

ParentInstanceId is included in the same places as InstanceId in the trace and log context (e.g. structured log properties, trace attributes). No configuration change is required; it is emitted automatically when a parent-child relationship exists.

Reference: #415 - Add InstanceId and Parent InstanceId to trace and log correlation (cross-domain subflow)

Configuration Updates​

Configuration for v0.0.38:

{
  "runtimeVersion": "0.0.38",
  "schemaVersion": "0.0.36"
}

Note: Schema version remains at 0.0.36; runtime v0.0.38 is backward compatible with schema v0.0.36.

Issues Referenced​

• #365 - App Version in Responses - Implementation
• #417 - feat(domain): Add AddHeader and RemoveHeader to tasks with Headers support
• #415 - Add InstanceId and Parent InstanceId to trace and log correlation (cross-domain subflow)

Summary​

With this release:

• X-App-Version is returned in all API response headers and on the Health endpoint for version identification.
• AddHeader and RemoveHeader are available on HttpTask, DaprServiceTask, and Trigger-family tasks for fine-grained header control in mappings.
• ParentInstanceId is included in trace and logging for cross-domain subflow correlation, improving observability for parent-child instance flows.

vNext Runtime Platform Team
March 9, 2026

This release introduces transition filtering by role grants in the State function (static roles plus $InstanceStarter / $PreviousUser), field-level visibility on the Flow Master schema via roleGrant (x-roles) for Data function and data-returning endpoints, remote view support (cross-domain view references), instance metadata in GetInstance/GetInstances responses, parent flow shared-transition execution when the instance is in a subflow (with $self target rule), and ErrorBoundary retry resolved by rule-based matching. It also adds flow version on instance (with automatic migration), View function content typed by view type (JSON vs string), hasView and hasSchema in the State function response to avoid unnecessary requests, and type-dependent content in the view definition schema.

Features​

1. Filter State-Function Transitions by Transition Role Grants​

The State function now returns available transitions filtered by the roles defined in the transition’s authorize configuration. Only transitions for which the caller has an allowed role (static roles or $InstanceStarter / $PreviousUser) are included in the response.

Behavior:

• Transitions without role restrictions remain available to all callers.
• Transitions with roles (roleGrant) are returned only when the caller holds an allowed role.
• Enables clients to show only transitions the user is authorized to execute.

Reference: #397 - Filter state-function transitions by transition role grants

2. Master Schema Field-Level Visibility (roleGrant / x-roles)​

The Flow Master schema supports field-level visibility via a roleGrant (roles) property on schema fields. Data functions and data-returning endpoints (Get Instance, GetInstances, etc.) run the authorize layer and expose only fields the caller is allowed to see.

Example (Master schema properties with roles):

{
  "properties": {
    "amount": {
      "type": "number",
      "roles": [
        { "role": "morph-idm.maker", "grant": "allow" },
        { "role": "morph-idm.approver", "grant": "allow" },
        { "role": "morph-idm.viewer", "grant": "allow" }
      ]
    },
    "internalNotes": {
      "type": "string",
      "roles": [
        { "role": "morph-idm.approver", "grant": "allow" },
        { "role": "morph-idm.manager", "grant": "allow" }
      ]
    },
    "publicStatus": {
      "type": "string"
    }
  }
}

Properties without roles are visible to all authorized callers. For third-party and tooling compatibility, a roles vocabulary is published:

• roles-vocab.json

Reference: #402 - Implement master schema field-level visibility with x-roles for function responses

3. Predefined System Roles ($InstanceStarter, $PreviousUser)​

Two static system roles are available in the roleGrant schema for instance authorization:

Example:

{
  "roles": [
    { "role": "$InstanceStarter", "grant": "allow" },
    { "role": "$PreviousUser", "grant": "allow" }
  ]
}

They can be used in transition roles, state/flow queryRoles, and Master schema field-level visibility.

Reference: #396 - Implement predefined system roles for instance authorization

4. Support Remote View in View Function​

Views can now be referenced and used across domains. Cross-domain view references allow shared views to be reused, versioned, and distributed in a single place instead of duplicating them per domain.

Behavior:

• View function can resolve and return view content from another domain.
• Enables central view libraries and consistent UI across domains.

Reference: #431 - Support remote view in View function

5. Instance Metadata in GetInstance / GetInstances Response​

GetInstance and GetInstances responses now include instance metadata and audit information in addition to the instance data. Clients receive a full instance envelope: identity, key, flow, domain, flow version, ETag, tags, metadata (state, status, timestamps, createdBy, modifiedBy, etc.), attributes, and extensions.

Example response shape (v0.0.39+):

{
  "id": "f226a728-9fa7-49ee-ab4e-3e8b84184df6",
  "key": "449874961045",
  "flow": "account-opening",
  "domain": "core",
  "flowVersion": "1.0.0",
  "etag": "\"01KJZXDY3N8ZKYB4RDHDWWWS7P\"",
  "tags": ["test", "banking", "account-openning", "key-test"],
  "metadata": {
    "currentState": "account-details-input",
    "effectiveState": "account-details-input",
    "status": "A",
    "effectiveStateType": "intermediate",
    "effectiveStateSubType": "none",
    "createdAt": "2026-03-05T21:10:56.857956Z",
    "modifiedAt": "2026-03-05T21:10:58.697809Z",
    "createdBy": "46467491018",
    "createdByBehalfOf": "34987491018",
    "modifiedBy": "46467491018",
    "modifiedByBehalfOf": "34987491018"
  },
  "attributes": { "initial": { "session": "16" }, "accountType": "demand-deposit", "userSession": {} },
  "extensions": {}
}

Reference: #432 - Include instance metadata in GetInstances list response

6. Trigger Parent Flow Transition from Subflow (Shared-Transition)​

When an instance is in a subflow, the parent flow’s shared transition can now be executed. Previously, only the subflow’s shared transition was available.

Important rule: If a shared transition is available while the instance is in a subflow, its target must be $self (so the transition applies to the current—parent—context when invoked from the subflow).

Reference: #425 - Trigger parent flow transition from subflow (shared-transition policy)

Bug Fixes​

ErrorBoundary: Resolve Retry Policy by Matching Rule (Error-Aware Retry)​

ErrorBoundary execution was updated so that retry is resolved by matching the error to the correct rule. Infrastructure-level errors were previously incorrectly included in the boundary; this is fixed and retry behavior is now rule-based (error-aware).

Reference: #421 - ErrorBoundary: Resolve retry policy by matching rule (error-aware retry)

Tasks / Improvements​

Flow Version on Instance​

The flow version with which an instance was started is now stored on the instance and used for transitions. This ensures the instance continues on the same flow version it was started with. Runtime runs an automatic migration per flow schema; no manual migration step is required.

Reference: #428 - Hotfix: Store flow version on instance and use it for transitions

View Function Content Typed by View Type​

The View function content is now returned with a type that matches the view type:

• type === "Json" → content is an object or array (JSON).
• type === "Html" (and similar) → content is a string (in JSON).

Clients can parse and use the response without re-parsing JSON strings for Json views.

Reference: #429 - View function should return content typed by view type (JSON vs string)

hasView and hasSchema in State Function Response​

The State function response now includes hasView and hasSchema where applicable (e.g. on the root view object and on each transition’s view and schema). Clients can avoid unnecessary view or schema requests and reduce 404s by checking these flags before calling the view or schema endpoints.

Example (excerpt):

{
  "view": { "hasView": true, "loadData": true, "href": "..." },
  "transitions": [
    {
      "name": "select-demand-deposit",
      "view": { "hasView": false, "loadData": true, "href": "..." },
      "schema": { "hasSchema": true, "href": "..." }
    }
  ]
}

Reference: #430 - Add hasView to state function response to avoid unnecessary view requests

View Definition: Type-Dependent Content Field (Schema)​

The view definition schema now allows content to be string or JSON depending on view type (e.g. Json → object/array, Html → string). This improves conflict handling in version control and design tools while remaining backward compatible.

Reference: vnext-schema #85 - View definition: type-dependent content field (string | JSON) with backward compatibility

Configuration Updates​

Configuration for v0.0.39:

{
  "runtimeVersion": "0.0.39",
  "schemaVersion": "0.0.37"
}

Note: This version includes a database migration. The runtime runs it automatically for each flow schema. Schema version is 0.0.37; ensure your configuration and tooling use the updated schema.

Issues Referenced​

• #396 - Implement predefined system roles for instance authorization ($InstanceStarter, $PreviousUser)
• #397 - Filter state-function transitions by transition role grants
• #402 - Implement master schema field-level visibility with x-roles for function responses
• #421 - ErrorBoundary: Resolve retry policy by matching rule (error-aware retry)
• #425 - Trigger parent flow transition from subflow (shared-transition policy)
• #428 - Hotfix: Store flow version on instance and use it for transitions
• #429 - View function should return content typed by view type (JSON vs string)
• #430 - Add hasView to state function response to avoid unnecessary view requests
• #431 - Support remote view in View function
• #432 - Include instance metadata in GetInstances list response
• vnext-schema #85 - View definition: type-dependent content field

Summary​

With this release:

• State function returns only transitions allowed by role grants (including $InstanceStarter and $PreviousUser) and exposes hasView / hasSchema to avoid unnecessary requests.
• Master schema supports field-level visibility via roleGrant (x-roles); Data function and data endpoints return only authorized fields.
• System roles $InstanceStarter and $PreviousUser are available for authorization and visibility.
• View function supports remote (cross-domain) views and returns content typed by view type (JSON vs string).
• GetInstance / GetInstances include instance metadata and audit fields in the response.
• Shared transitions can run on the parent flow when the instance is in a subflow; target must be $self in that case.
• ErrorBoundary retry is rule-based (error-aware); infrastructure errors are no longer incorrectly handled by the boundary.
• Flow version is stored on the instance and used for transitions; runtime performs automatic migration.
• View definition schema allows type-dependent content (string | JSON) with backward compatibility.

vNext Runtime Platform Team
March 9, 2026

This release adds Master Schema validation for workflow definitions, CurrentTransition in ScriptContext for transition data access in mappings, a full Authorization mechanism (roles and queryRoles) with permissions and authorize endpoints, and OrderBy support for instance queries. It also includes bug fixes for status/state filtering, function execution validation, and GroupBy with filter support (with a breaking change: filter array format removed).

Features​

1. Master Schema for Workflow Definitions​

Flow definitions can reference a master schema that validates all instance data throughout the instance lifecycle. When a master schema is defined, every write to instance data is validated against it; if validation fails, the instance is stopped.

Flow definition example:

{
    "schema": {
        "key": "token-master",
        "domain": "morph-idm",
        "version": "1.0.0",
        "flow": "sys-schemas"
    }
}

Behavior:

• If a flow has a master schema reference, all data added to instance data during the instance lifetime is validated against that schema.
• Invalid data causes the instance to be terminated.

Reference: #110 - Master Schema for Workflow Definitions

2. CurrentTransition Property on ScriptContext​

Input and transition mappings can now access the original transition request (body and headers) via ScriptContext.CurrentTransition. This allows using transition data in mappings without writing it to instance data.

Usage:

context.CurrentTransition.Data   // dynamic - original transition request body
context.CurrentTransition.Header // dynamic - original transition request headers (lowercase keys)

Use transition mapping to process data you do not want in instance data; the original transition payload remains available via CurrentTransition for the rest of the mapping pipeline.

Reference: #385 - Add CurrentTransition property to ScriptContext

3. Authorization Mechanism (Roles and QueryRoles)​

Function, flow, state, and transition definitions support roles and queryRoles for authorization. The following system function endpoints expose permissions and authorization checks.

Function definition with roles:

{
  "name": "calculateFee",
  "roles": [
    { "role": "morph-idm.maker", "grant": "allow" },
    { "role": "morph-idm.viewer", "grant": "allow" }
  ]
}

Transition roles:

{
  "key": "submit",
  "target": "pending",
  "roles": [
    { "role": "morph-idm.maker", "grant": "allow" },
    { "role": "morph-idm.initiator", "grant": "allow" }
  ]
}

Flow and state queryRoles:

{
  "workflow": "payment-approval",
  "queryRoles": [
    { "role": "morph-idm.viewer", "grant": "allow" }
  ],
  "states": [
    {
      "key": "draft",
      "queryRoles": [
        { "role": "morph-idm.maker", "grant": "allow" },
        { "role": "morph-idm.viewer", "grant": "deny" }
      ]
    },
    {
      "key": "approved",
      "type": "finish",
      "queryRoles": []
    }
  ]
}

Endpoints:

Get Flow Permissions

GET /api/v1/core/workflows/account-opening/functions/permissions

Example response:

{
    "workflow": "account-opening",
    "queryRoles": [
        { "role": "morph-idm.viewer", "grant": "allow" }
    ],
    "states": [
        { "key": "account-type-selection", "queryRoles": [] },
        {
            "key": "account-details-input",
            "queryRoles": [
                { "role": "morph-idm.maker", "grant": "allow" },
                { "role": "morph-idm.viewer", "grant": "deny" }
            ]
        }
    ],
    "transitions": [
        { "key": "initiate-account-opening", "target": "account-type-selection", "roles": [] },
        {
            "key": "select-demand-deposit",
            "target": "account-details-input",
            "roles": [
                { "role": "morph-idm.maker", "grant": "allow" },
                { "role": "morph-idm.initiator", "grant": "allow" }
            ]
        }
    ],
    "functions": []
}

Get Instance Permissions

GET /api/v1/core/workflows/account-opening/instances/{instanceId}/functions/permissions

Returns the same structure as Get Flow Permissions; for instances in a subflow, returns the active subflow’s permissions.

Flow Authorize

Checks whether the given role is allowed for the given transition (or function) on the flow. Optional version; if omitted, latest is used.

GET /api/v1/core/workflows/account-opening/functions/authorize?transitionKey=submit-account-details&role=morph-idm.maker&version=1.0.0

Response 200:

{ "allowed": true }

Response 403:

{ "allowed": false }

Instance Authorize

GET /api/v1/core/workflows/account-opening/instances/{instanceId}/functions/authorize?queryRoles=true&role=morph-idm.viewer

Same response shape as Flow Authorize. With queryRoles=true, permission is evaluated against the instance’s current state (and flow/state queryRoles); for subflows, the active subflow instance is used.

Authorize query parameters:

Reference: #382 - Authorization Mechanism

4. OrderBy Support for Instance Queries​

Instance list and data endpoints support sorting via sort or orderBy query parameters.

Single field:

?sort={"field":"createdAt","direction":"desc"}
?orderBy={"field":"status","direction":"asc"}

Multiple fields:

?sort={"fields":[{"field":"status","direction":"asc"},{"field":"createdAt","direction":"desc"}]}

• direction: "asc" or "desc" (case-insensitive). Defaults to "asc" if omitted.

Sortable fields:

Instance columns are applied in the database; attributes.* ordering uses the latest instance data JSON and is subject to the same schema/security as filtering.

Reference: #381 - Order By Support Implementation

Bug Fixes​

1. Status and State Filter​

Filtering on status and state (currentState) now works correctly in instance queries.

Reference: #389 - Filter status property not working

2. Function Execution Validation​

The runtime now validates that a function is defined in the workflow’s functions collection before execution. Executing an undefined function returns an error.

Reference: #180 - Function execution should validate function is defined in workflow's functions collection

3. GroupBy and Filter Together (Breaking Change)​

GroupBy and filter can now be used together in the same query. As part of this fix, the filter format has been standardized and the previous array form is no longer supported.

Breaking change:

• Before: "filter": ["expr1", "expr2"] (array) was supported.
• After: Only a single expression is supported: "filter": "expr" (string). The GraphQL-style filter format is now the single standard.

If you currently pass filter as an array, update to a single expression (e.g. combine conditions with and/or in one expression).

Reference: #392 - GroupBy and Filtering queries not working together

Configuration Updates​

Configuration for v0.0.37:

{
  "runtimeVersion": "0.0.37",
  "schemaVersion": "0.0.36"
}

Note: Schema version remains at 0.0.36; runtime v0.0.37 is backward compatible with schema v0.0.36.

Issues Referenced​

• #110 - Master Schema for Workflow Definitions
• #385 - Add CurrentTransition property to ScriptContext
• #382 - Authorization Mechanism
• #381 - Order By Support Implementation
• #389 - Filter status property not working
• #180 - Function execution should validate function is defined in workflow's functions collection
• #392 - GroupBy and Filtering queries not working together

Summary​

With this release:

• Master Schema validates all instance data for flows that reference it; invalid data stops the instance.
• ScriptContext.CurrentTransition provides access to the original transition body and headers in mappings.
• Authorization supports roles and queryRoles on functions, flows, states, and transitions, with permissions and authorize endpoints.
• Instance queries support OrderBy/sort with single or multiple fields and a defined set of sortable fields.
• Status and state filtering works correctly; function execution is validated against the workflow’s functions; GroupBy and filter work together, with filter standardized to a single expression (breaking change for filter array usage).

vNext Runtime Platform Team
February 17, 2026

This release includes critical hotfixes, bug fixes, and a new incident retry feature. Key highlights include gateway base URL support for cross-domain routing, domain replacement fixes in init service, task execution pipeline improvements, and a new retry endpoint for faulted instances.

Hotfixes​

1. Support Gateway Base URL in InstanceUrlTemplates for Cross-Domain Routing​

Added support for configurable URL templates in Hateoas-style responses when using a gateway. This enables proper URL generation in gateway-based deployments.

Configuration:

Add the following configuration to your appsettings.json:

{
  "UrlTemplates": {
    "Start": "/api/{0}/workflows/{1}/instances/start",
    "Transition": "/api/{0}/workflows/{1}/instances/{2}/transitions/{3}",
    "FunctionList": "/api/{0}/workflows/{1}/functions/{2}",
    "InstanceList": "/api/{0}/workflows/{1}/instances",
    "Instance": "/api/{0}/workflows/{1}/instances/{2}",
    "InstanceHistory": "/api/{0}/workflows/{1}/instances/{2}/transitions",
    "Data": "/api/{0}/workflows/{1}/instances/{2}/functions/data",
    "View": "/api/{0}/workflows/{1}/instances/{2}/functions/view",
    "Schema": "/api/{0}/workflows/{1}/instances/{2}/functions/schema?transitionKey={3}"
  }
}

Template Parameters:

• {0} - Domain
• {1} - Workflow/Flow name
• {2} - Instance ID
• {3} - Transition key or other context-specific parameter

Use Case: When using an API gateway in front of the vNext platform, configure these templates to match your gateway's routing rules.

Documentation Updated:

• doc/en/services/init-service.md
• doc/tr/services/init-service.md

Reference: #327 - Support gateway base URL in InstanceUrlTemplates for cross-domain routing

Bug Fixes​

1. Preserve Config and Process Objects During Domain Replacement in Package-API-Server​

Fixed an issue where the domain replacement operation in the init service was incorrectly replacing domain values within nested component data such as "process" and "config" objects during package deployment.

Issue: When deploying components via init service, the domain control and replacement operation was too aggressive, replacing domain references in nested component configurations where they should have been preserved.

Fix: Domain replacement now correctly preserves "process" and "config" sub-component data integrity during deployment.

Reference: #373 - fix: Preserve config and process objects during domain replacement in package-api-server

2. Task Execution Pipeline and Cache Synchronization Improvements​

Multiple improvements to the task execution pipeline and cache synchronization:

Changes:

1. SubProcess Header Handling Fix
   Resolved an error in subprocess startup caused by incorrect header usage.

2. TriggerTask Extensions
   Added Headers and TimeoutSeconds fields to all TriggerTask types:

   • StartTask (Type 11)
   • DirectTriggerTask (Type 12)
   • GetInstanceDataTask (Type 13)
   • SubProcessTask (Type 14)

3. Cache Invalidation Consistency
   Fixed inconsistencies in cache invalidation after publish operations.

4. Task Error Logging Fix
   Corrected error logging issues in task execution.

5. Minor Improvements
   Various other minor enhancements and refinements.

Documentation Updated:

• doc/en/flow/tasks/trigger-task.md
• doc/tr/flow/tasks/trigger-task.md

Reference: #377 - Refactor: Task Execution Pipeline and Cache Synchronization Improvements

Features​

1. Incident Retry Endpoint (Resume from Failed Task)​

Added a new retry endpoint that allows resuming workflow instances that have entered a "Faulted" state. This endpoint enables recovery from failed tasks by retrying from the point of failure.

Endpoint:

POST /api/v1/{domain}/workflows/{workflow}/instances/{instanceId}/retry?version={version}&sync={sync}
Content-Type: application/json

{
  "key": "",
  "tags": [],
  "attributes": {}
}

Parameters:

Request Body:

All fields are optional and follow the standard instance payload schema:

{
  "key": "",           // Instance key (optional)
  "tags": [],          // Instance tags (optional)
  "attributes": {}     // Additional data to merge with instance state (optional)
}

Requirements:

• ✅ Instance must be in "Faulted" state
• ✅ Only available for faulted instances
• ❌ Cannot be used on instances in other states (Active, Completed, etc.)

Example Request:

POST /api/v1/ecommerce/workflows/payment-processing/instances/18075ad5-e5b2-4437-b884-21d733339113/retry?version=1.0.0&sync=true
Content-Type: application/json

{
  "tags": ["retry-attempt-1"],
  "attributes": {
    "retryReason": "Network timeout recovered",
    "retriedBy": "system-admin",
    "retryTimestamp": "2026-02-06T10:30:00Z"
  }
}

Example Response (Success):

{
  "id": "18075ad5-e5b2-4437-b884-21d733339113",
  "status": "A"
}

Error Scenarios:

Not Faulted:

{
  "type": "https://httpstatuses.com/400",
  "title": "Bad Request",
  "status": 400,
  "detail": "Instance is not in Faulted state. Current state: Active",
  "instance": "/api/v1/ecommerce/workflows/payment-processing/instances/18075ad5-e5b2-4437-b884-21d733339113/retry"
}

Instance Not Found:

{
  "type": "https://httpstatuses.com/404",
  "title": "Not Found",
  "status": 404,
  "detail": "Instance not found",
  "instance": "/api/v1/ecommerce/workflows/payment-processing/instances/18075ad5-e5b2-4437-b884-21d733339113/retry"
}

Use Cases:

1. Transient Failure Recovery
   Retry after temporary infrastructure issues (network timeout, service unavailable)

2. Data Correction and Retry
   Fix data issues and retry the failed task

3. Manual Intervention
   Allow operators to manually resume workflows after investigating failures

4. Automated Retry Strategies
   Implement retry logic in external monitoring systems

Documentation Updated:

• doc/en/how-to/start-instance.md
• doc/tr/how-to/start-instance.md

Reference: #290 - Incident Retry Endpoint (Resume from Failed Task)

Configuration Updates​

Configuration for v0.0.36:

{
  "runtimeVersion": "0.0.36",
  "schemaVersion": "0.0.35"
}

Note: Schema version remains unchanged from v0.0.35 (v0.0.36 runtime is backward compatible with schema v0.0.35).

Issues Referenced​

• #327 - Support gateway base URL in InstanceUrlTemplates for cross-domain routing
• #373 - fix: Preserve config and process objects during domain replacement in package-api-server
• #377 - Refactor: Task Execution Pipeline and Cache Synchronization Improvements
• #290 - Incident Retry Endpoint (Resume from Failed Task)

Summary​

With this release:

• ✅ Added gateway base URL support for cross-domain routing via configurable URL templates
• ✅ Fixed domain replacement issues in init service during package deployment
• ✅ Enhanced TriggerTask types with Headers and TimeoutSeconds support
• ✅ Improved cache invalidation consistency and task error logging
• ✅ Added new retry endpoint for recovering faulted workflow instances

vNext Runtime Platform Team
February 6, 2026

This combined release document covers v0.0.34 and v0.0.35. It includes cache invalidation synchronization improvements across pods via a broadcast pub/sub pattern, deterministic handling for non-blocking task failures across the transition pipeline, and a new sync configuration flag for SubProcessTask.

v0.0.34​

Bug Fixes​

1. Prevent Out-of-Flow State Transition Triggering​

Fixed a bug where a state transition could be triggered independently from any point, allowing the flow state to be moved to an unintended stage.

Reference: #342 - The state transition can be triggered independently from any point, allowing the flow state to be moved to a different stage

v0.0.35​

Hotfixes​

1. Cache Invalidation Broadcast (Cross-Pod Synchronization)​

Implemented a broadcast-based cache invalidation approach so cache refresh events can be received by all pods (instead of only the pod that received the request).

Runtime configuration (Dapr):

• vnext-pubsub-broadcast component is available on orchestration/execution/workers.
• Orchestration subscribes to the invalidation topic and routes it to the utility endpoint.

Dapr component:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: vnext-pubsub-broadcast
spec:
  type: pubsub.redis
  metadata:
  - name: redisHost
    value: vnext-redis:6379

Dapr subscription (orchestration):

apiVersion: dapr.io/v1alpha1
kind: Subscription
metadata:
  name: vnext-invalidate-cache-subscription
spec:
  topic: development.vnext.invalidate-cache
  route: /api/v1/utilities/invalidate
  pubsubname: vnext-pubsub-broadcast

Reference: #356 - Cache Invalidation Broadcast System Implementation

Enhancements​

1. Deterministic Handling for Non-Blocking Task Failures (Transition Pipeline)​

Enhanced the transition pipeline to consistently capture business-level, non-blocking task failures (i.e., failures not handled by ErrorBoundary) and ensure they are either:

• routed/handled via AutoTransitions, or
• faulted with a clear consolidated error when unhandled (e.g., epilogue skipped, no auto transitions available, or no winner).

Reference: #369 - Handle non-blocking task failures across transition pipeline + add SubProcess sync flag

2. SubProcessTask sync Configuration (v0.0.35+)​

SubProcessTask now supports a sync flag in its config. This value is propagated end-to-end and sent explicitly as the sync=true|false query parameter in the subprocess start request.

Example:

{
  "type": "14",
  "config": {
    "domain": "audit",
    "key": "transaction-audit",
    "version": "1.0.0",
    "sync": false
  }
}

Documentation updated:

• doc/en/flow/tasks/trigger-task.md
• doc/tr/flow/tasks/trigger-task.md

Reference: #369 - Handle non-blocking task failures across transition pipeline + add SubProcess sync flag

Configuration Updates​

Configuration for v0.0.35:

{
  "runtimeVersion": "0.0.35",
  "schemaVersion": "0.0.34"
}

Note: Schema version remains unchanged from v0.0.34 (v0.0.35 runtime is backward compatible with schema v0.0.34).

Issues Referenced​

• #342 - The state transition can be triggered independently from any point, allowing the flow state to be moved to a different stage
• #356 - Cache Invalidation Broadcast System Implementation
• #369 - Handle non-blocking task failures across transition pipeline + add SubProcess sync flag

Summary​

With this release:

• Fixed unintended out-of-flow state transition triggering
• Added a broadcast pub/sub pattern for cache invalidation across pods
• Improved deterministic propagation/handling of non-blocking task failures in transition pipeline
• Added SubProcessTask sync flag and updated documentation accordingly

vNext Runtime Platform Team
February 3, 2026

This release introduces multi-domain support for local development environments, upgrades to .NET 10 LTS, and enhances state tracking with HumanTask support. Additionally, important improvements to Service Discovery validation, TriggerTask SSL configuration, and instance filtering capabilities have been implemented.

New Features​

1. Multi-Domain Support in vNext Runtime​

Added comprehensive multi-domain support for local development environments, allowing teams to run isolated domain environments simultaneously.

Details:

• Run multiple domains (e.g., core, sales, hr) on the same infrastructure
• Shared PostgreSQL, Redis, Vault, and Dapr services
• Domain-specific port allocation with configurable offsets
• Template-based domain creation from vnext/docker/templates/
• Automatic database name generation (e.g., core → vNext_Core)

Features:

• Pre-configured core (offset 0) and discovery (offset 5) domains included
• Create custom domains with make create-domain DOMAIN=mydom PORT_OFFSET=10
• Manage individual domains independently
• View all running domains with make status-all-domains
• Domain-specific environment files and configurations
• Reserved offsets (0 and 5) prevent conflicts with system domains

Example Workflow:

# Start shared infrastructure
make up-infra

# Pre-configured domains (core and discovery) are ready to use
make up-vnext DOMAIN=core
make up-vnext DOMAIN=discovery

# Create and start your custom domain (use offset 10 or higher)
make create-domain DOMAIN=sales PORT_OFFSET=10
make db-create DOMAIN=sales
make up-vnext DOMAIN=sales

Port Allocation:

⚠️ Reserved Offsets: The core and discovery domains are provided as pre-configured domains with offsets 0 and 5 respectively. Do not use these offsets for your custom domains. Start with offset 10 or higher for new domains.

Note: For complete documentation, see the Multi-Domain Support section in README.md

Enhancements​

1. Upgrade to .NET 10 (LTS)​

Upgraded the entire platform to .NET 10 LTS for improved performance, security, and access to latest framework features.

Benefits:

• Enhanced performance and memory management
• Latest language features and APIs
• Long-term support for production deployments
• Improved diagnostics and tooling

Reference: #168 - Upgrade to .NET 10 (LTS)

2. HumanTask State Tracking for Pending Instance Queries​

Implemented comprehensive state tracking for human task workflows with new state subtypes and instance-level fields.

Details:

• New State SubTypes: Busy (code: 5) and Human (code: 6)
• New Instance fields: EffectiveStateType and EffectiveStateSubType
• Enhanced filtering capabilities for pending instance queries
• Automatic database migration on startup

State SubType Mapping:

Instance Fields:

• EffectiveStateType: Current effective state type
• EffectiveStateSubType: Current effective state subtype

Use Cases:

• Query all instances awaiting human interaction
• Filter workflows in processing state
• Track human task queues across workflows
• Generate workload reports by state type

Filter Example:

GET /core/workflows/approval-flow/instances?filter={"effectiveStateSubType":{"eq":"6"}}

Migration: The database migration for new columns is applied automatically on startup.

Reference: #328 - Add HumanTask state tracking for pending instance queries

3. Persist InputHandler Result to InstanceTask.Request​

InputHandler results are now persisted to the InstanceTask.Request field for complete task audit trail.

Details:

• Input handler transformation results are stored
• Enables full task execution audit trail
• Supports debugging and compliance requirements
• Request data available for historical analysis

Benefits:

• Complete visibility into task input data
• Track data transformations across task execution
• Support for compliance and audit requirements
• Enhanced debugging capabilities

Reference: #309 - Persist InputHandler result to InstanceTask.Request

Bug Fixes​

1. Cannot Select $self as Target Value in Cancel Transitions​

Fixed issue where $self could not be used as a target in cancel transitions.

Problem:

• Cancel transitions couldn't use $self as target
• Schema validation prevented valid use cases

Solution:

• Added $self target support in vnext-schema for cancel transitions
• Enables workflows to cancel and remain in current state

Reference: #307 - Cannot select $self as target value in cancel transitions

2. EffectiveState Display Issue from Nested Subflows​

Fixed EffectiveState calculation error when displaying state from deeply nested subflow structures.

Problem:

• EffectiveState showed incorrect values for nested subflows
• Bottom-up state propagation had calculation errors

Solution:

• Corrected bottom-up effective state display algorithm
• Ensures accurate state representation across nested workflows

Reference: #316 - EffectiveState aktif son state gösterme sorunu

3. Align TriggerInvokers HttpClient Configuration with HttpTaskInvoker​

Centralized and standardized HttpClient Factory configuration across all TriggerTask types.

Details:

• Unified HttpClient Factory behavior for StartTask, DirectTriggerTask, GetInstanceDataTask, and SubProcessTask
• Added validateSsl attribute to TriggerTask configuration
• Consistent SSL validation across all task types

New Configuration:

{
  "type": "11",
  "config": {
    "domain": "core",
    "flow": "my-flow",
    "validateSsl": true
  }
}

validateSsl Attribute:

Warning: Disable SSL validation only in development or trusted internal environments.

Reference: #320 - Align TriggerInvokers HttpClient Configuration with HttpTaskInvoker

Hotfixes​

1. NotificationMapping Does Not Handle Subflow Data Returned from State Endpoint​

Fixed notification mapping to correctly handle subflow data from state endpoints.

Problem:

• NotificationMapping didn't align with current state behavior for subflow data
• Subflow state information missing in notifications

Solution:

• Updated notification mapping to match current state behavior
• Ensures consistent subflow data handling across all endpoints

Reference: #283 - NotificationMapping.csx does not handle subflow data returned from state endpoint

2. Fail Fast When vNextApi:BaseUrl Points to Localhost in Production​

Implemented validation to prevent localhost addresses in production Service Discovery configuration.

Details:

• Application validates vNextApi:BaseUrl setting on startup
• Localhost addresses (localhost, 127.0.0.1) are blocked in production environments
• Fail-fast behavior prevents deployment with incorrect configuration

Validation Rules:

• Development environment: Localhost allowed
• Production environment: Localhost blocked and application fails to start

Error Example:

FATAL: Service Discovery configuration error - 
vNextApi:BaseUrl cannot point to localhost in production environment.
Current value: http://localhost:4201

Configuration:

{
  "vNextApi": {
    "BaseUrl": "https://api.production.com"  // Must be resolvable address
  }
}

Reference: #313 - Fail fast when vNextApi:BaseUrl points to localhost in production

3. Service Discovery Registration Failure Crash​

Application now crashes immediately when Service Discovery is enabled but registration fails.

Details:

• Fail-fast behavior when Service Discovery registration fails
• Prevents silent failures in service mesh environments
• Ensures deployment issues are detected immediately

Behavior:

• Service Discovery enabled + Registration successful: Normal operation
• Service Discovery enabled + Registration failed: Application crash
• Service Discovery disabled: No validation

Error Handling:

FATAL: Service Discovery registration failed.
Cannot proceed without successful service registration.
Check network connectivity and Service Discovery endpoint configuration.

Note: This ensures that microservice deployments with Service Discovery don't run in a partially configured state.

Reference: #325 - Refactor: Move service discovery enable check into RegisterDomainAsync and add failure handling

4. Fail-Fast Extension Execution with Error Target Details​

Extension tasks now fail immediately with detailed error information when errors occur.

Details:

• Extension errors terminate request immediately
• Error target details logged for troubleshooting
• Detailed error response returned to client

Error Response:

{
  "type": "https://httpstatuses.com/500/extension-error",
  "title": "Extension Execution Failed",
  "status": 500,
  "detail": "Extension 'validate-customer' failed during execution",
  "errorTarget": "CustomerValidationExtension",
  "targetEndpoint": "https://extensions.api.com/validate",
  "traceId": "00-abc123-def456-01"
}

Benefits:

• Fast failure detection
• Detailed error context for debugging
• Prevents cascade failures

Reference: #306 - Fail-fast extension execution with error target details

5. Add EffectiveState Column and Update Alias Handling​

Enhanced instance filtering with EffectiveState field support.

Details:

• EffectiveState information added to instance filtering queries
• Improved alias handling for state-related fields
• Better query performance for state-based searches

Filterable Fields:

• effectiveState: Current effective state
• effectiveStateType: Current effective state type
• effectiveStateSubType: Current effective state subtype

Reference: #317 - Add EffectiveState column and update alias handling

Other Changes​

1. Documentation Reorganization​

Reorganized and improved vNext technical documentation structure for better discoverability and maintainability.

Improvements:

• Enhanced documentation structure
• Improved navigation and organization
• Better categorization of topics
• Updated examples and guides

Reference: #310 - Reorganize documentation structure for improved discoverability and maintainability

Configuration Updates​

Configuration for v0.0.33:

{
  "runtimeVersion": "0.0.32",
  "schemaVersion": "0.0.33",
  "componentVersion": "0.0.18"
}

Issues Referenced​

New Features:

• #168 - Upgrade to .NET 10 (LTS)
• vnext-runtime multi-domain support (README.md documentation)

Enhancements:

• #309 - Persist InputHandler result to InstanceTask.Request
• #328 - Add HumanTask state tracking for pending instance queries

Bug Fixes:

• #307 - Cannot select $self as target value in cancel transitions
• #316 - EffectiveState aktif son state gösterme sorunu
• #320 - Align TriggerInvokers HttpClient Configuration with HttpTaskInvoker

Hotfixes:

• #283 - NotificationMapping.csx does not handle subflow data returned from state endpoint
• #306 - Fail-fast extension execution with error target details
• #313 - Fail fast when vNextApi:BaseUrl points to localhost in production
• #317 - Add EffectiveState column and update alias handling
• #325 - Refactor: Move service discovery enable check into RegisterDomainAsync and add failure handling

Other:

• #310 - Reorganize documentation structure for improved discoverability and maintainability

Summary​

With this release:

• Multi-domain support for local development environments added
• .NET 10 LTS upgrade completed
• HumanTask state tracking with EffectiveStateType and EffectiveStateSubType fields implemented
• InputHandler results now persisted to InstanceTask.Request
• Cancel transitions support $self target
• EffectiveState display issue for nested subflows fixed
• TriggerTask types now support validateSsl attribute
• NotificationMapping aligned with current state behavior
• Service Discovery localhost validation in production implemented
• Service Discovery registration failure now causes immediate crash
• Extension tasks fail-fast with detailed error information
• EffectiveState column added to instance filtering
• Documentation structure reorganized

Upgrade Path​

From v0.0.31 to v0.0.33:​

1. Update Runtime:

   git pull origin master
   

2. Update Configuration:

   {
     "runtimeVersion": "0.0.32",
     "schemaVersion": "0.0.33",
     "componentVersion": "0.0.18"
   }
   

3. Database Migration: The EffectiveStateType and EffectiveStateSubType field migrations are applied automatically on startup.

4. Review Service Discovery Configuration: If using Service Discovery, ensure vNextApi:BaseUrl does not point to localhost in production environments.

5. Review TriggerTask Configurations: If you have custom TriggerTask configurations, you can now optionally add the validateSsl attribute (defaults to true).

6. (Optional) Explore Multi-Domain Support: For local development, explore the new multi-domain capabilities:

   # Start infrastructure and pre-configured domains
   make up-infra
   make up-vnext DOMAIN=core
   make up-vnext DOMAIN=discovery
   
   # Create custom domains (use offset 10 or higher)
   make create-domain DOMAIN=mydom PORT_OFFSET=10
   make db-create DOMAIN=mydom
   make up-vnext DOMAIN=mydom
   

   Note: Offsets 0 and 5 are reserved for core and discovery domains.

vNext Runtime Platform Team
January 26, 2026

This release introduces significant new features including the GetInstances Task for cross-workflow data fetching, Subflow State Change Events with EffectiveState field, and Update Parent Data Transition for SubFlow-to-parent communication. Additionally, important bug fixes for HTTP request size limits, extension query string formatting, array merge behavior, and correlation conflict handling have been implemented.

New Features​

1. GetInstances Task​

Added a new task type for fetching instance data from other workflows with pagination and filtering support.

Details:

• Task Type: 15
• Enables cross-workflow data queries
• Supports pagination with page and pageSize parameters
• Supports sorting with sort parameter (e.g., -CreatedAt for descending)
• Supports filtering with filter array parameter
• Optional Dapr service invocation support

Task Configuration:

{
  "key": "fetch-orders",
  "version": "1.0.0",
  "domain": "core",
  "flow": "sys-tasks",
  "flowVersion": "1.0.0",
  "tags": ["data-fetch", "workflow-communication"],
  "attributes": {
    "type": "15",
    "config": {
      "domain": "core",
      "flow": "order-flow",
      "page": 1,
      "pageSize": 10,
      "sort": "-CreatedAt"
    }
  }
}

Config Parameters:

Reference: #272 - Add Filter Support to GetInstances Task

2. Subflow State Change Event Implementation​

Implemented InstanceSubStateChangedEvent that fires when a subflow instance changes state, updating the parent's correlation and exposing EffectiveState.

Details:

• New EffectiveState field on Instance entity
• Automatically tracks subflow state in parent correlation
• Enables accurate long-polling state display
• Migration automatically applied

Behavior:

• If an instance has an active subflow, EffectiveState reflects the subflow's current state
• If an instance has no subflow dependency, EffectiveState reflects its own state
• Parent instance receives state change events from subflows

Architecture:

Reference: #297 - Subflow State Change Event Implementation

3. Update Parent Data Transition​

Added a special transition type for updating parent workflow instance data from SubFlow states.

Details:

• Special transition for SubFlow states only
• Target is always $self (no state change)
• Updates parent instance data without advancing the flow
• Uses update-parent-data well-known transition key

Workflow Configuration:

{
  "updateData": {
    "key": "update-parent",
    "target": "$self",
    "triggerType": 0,
    "versionStrategy": "None",
    "labels": [
      { "language": "en", "label": "Update Parent Data" },
      { "language": "tr", "label": "Parent Veri Güncelle" }
    ]
  }
}

What It Does:

• Data mapping (according to transition data mapping rules)
• Instance data update
• Instance key validation and setting
• Transition record creation
• Tag addition (if any)

What It Does NOT Do:

• State change (target is $self)
• SubFlow advancement
• Auto transition invocation
• OnExit/OnEntry task execution
• State change event publishing

Reference: #238 - Direct Trigger Task for Parent Transition

4. GraphQL-Style Filtering for Instance Data​

Implemented comprehensive GraphQL-style filtering support for instance data queries.

Features:

• Filter on Instance columns (key, status, state, createdAt, etc.)
• Filter on JSON data fields using attributes prefix
• 13 comparison operators (eq, ne, gt, ge, lt, le, between, like, startswith, endswith, in, nin, isnull)
• Logical operators (AND, OR, NOT)
• Group By with aggregations (count, sum, avg, min, max)

Supported Routes:

GET /{domain}/workflows/{workflow}/functions/data?filter={...}
GET /{domain}/workflows/{workflow}/instances?filter={...}

Example - Filter by Status and Amount:

GET /banking/workflows/payment/functions/data?filter={"status":{"eq":"Active"},"attributes":{"amount":{"gt":"1000"}}}

Example - Logical OR:

GET /banking/workflows/payment/functions/data?filter={"or":[{"status":{"eq":"Active"}},{"status":{"eq":"Busy"}}]}

Documentation: Instance Filtering Guide
Reference: #202 - Implement GraphQL-Style Filtering for Instance Data

5. Flexible Version Resolution in References​

Version references now support multiple resolution strategies for component versions.

Supported Formats:

Example Usage:

{
  "key": "validate-client",
  "domain": "core",
  "version": "latest",
  "flow": "sys-tasks"
}

Documentation: Reference Schema - Version Strategies
Reference: #209 - Support "latest" String Value in References

6. Enhanced Error Handling System (ErrorBoundary)​

Implemented comprehensive error handling with multi-level error resolution and priority-based execution.

Features:

• Multi-level error boundaries (Global, State, Task)
• Priority-based rule evaluation (lower number = higher priority)
• 6 error actions: Abort, Retry, Rollback, Ignore, Notify, Log
• Retry policies with exponential backoff and jitter
• Error filtering by type and code

Error Resolution Hierarchy:

Task-level → State-level → Global-level → System Default

Example Configuration:

{
  "errorBoundary": {
    "onError": [
      {
        "action": 1,
        "errorCodes": ["Task:503", "Task:504"],
        "priority": 10,
        "retryPolicy": {
          "maxRetries": 3,
          "initialDelay": "PT5S",
          "backoffType": 1
        }
      },
      {
        "action": 0,
        "errorCodes": ["*"],
        "transition": "error-state",
        "priority": 999
      }
    ]
  }
}

Note: onTimeout property exists in schema but is not yet implemented.

Documentation: Error Boundary Guide
Reference: #88 - Enhanced Error Handling System

Bug Fixes​

1. Request Size Issue Fix​

Fixed HTTP client and handler size limits to prevent failures when handling large request and response payloads.

Problem:

• Large HTTP request/response payloads caused failures due to buffer limits

Solution:

• Increased HTTP client buffering and header limits to accommodate larger payloads

Reference: #303 - Request size issue fix

2. Extension Query String Formatting Fix​

Fixed incorrect query string formatting for extensions parameter.

Problem:

• Multiple extensions were incorrectly combined with commas in a single parameter
• Current behavior: ?extensions=ext1,ext2,ext3

Solution:

• Each extension is now added as a separate query parameter
• Correct behavior:

?extensions=ext1
&extensions=ext2
&extensions=ext3

Reference: #273 - Incorrect query string formatting for extensions parameter

3. Array Merge Behavior Change​

Changed InstanceData merge logic to replace arrays instead of merging them.

Problem:

• Deep merge for arrays caused unintended behavior
• Removing items from arrays was not possible
• Array updates were non-deterministic

Solution:

• Arrays are now fully replaced (not merged)
• Objects continue to use deep merge behavior
• Primitives continue to be replaced

Merge Behavior:

Example:

Current data:

{ "items": [{ "id": 1 }, { "id": 2 }] }

Incoming payload:

{ "items": [{ "id": 2 }] }

Result (before - incorrect):

{ "items": [{ "id": 1 }, { "id": 2 }, { "id": 2 }] }

Result (after - correct):

{ "items": [{ "id": 2 }] }

Reference: #294 - Change merge behavior to replace arrays instead of merging

4. Correlation InstanceId Conflict Handling​

Fixed correlation instanceId mismatch when subflow returns a different instanceId due to idempotency.

Problem:

• Parent flow creates correlation with a generated instanceId
• Subflow detects an active instance with the same key
• Due to idempotency, subflow returns existing instanceId
• Correlation and actual subflow instance become inconsistent

Solution:

• Client requests maintain idempotency behavior
• Service-to-service platform calls now return 409 Conflict
• Prevents incorrect sub-correlation creation

Reference: #274 - Correlation instanceId is not updated when subflow returns a different instanceId due to idempotency

Hotfixes​

1. Workflow Instance Busy/Active Status Management​

Implemented proper Busy/Available status management for workflow instances.

Details:

• Instance is "Busy" during transition processing
• Instance becomes "Available" when processing completes and target state has only manual transitions
• Same rules apply to both main flow and subflow instances

Status Flow:

Status Meanings:

Reference: #288 - Workflow Instance Busy/Active Status Management

2. Publish Component Timeout Fix​

Resolved timeout issues for long-running publish component operations in init-service.

Problem:

• Publishing components can take a long time due to runtime waiting, package downloading, and file processing
• HTTP requests timeout before completion

Solution:

• Added configurable server timeout environment variables
• Default timeout increased to 10 minutes

New Environment Variables:

Example Configuration (30 minutes):

services:
  vnext-init:
    environment:
      SERVER_TIMEOUT_MS: 1800000
      SERVER_KEEP_ALIVE_TIMEOUT_MS: 1800000
      SERVER_HEADERS_TIMEOUT_MS: 1810000

Reference: #268 - Publish component request times out for long-running operations

Improvements​

1. C# 12 Script Engine Support​

The script engine compiler now supports C# 12 features for mapping scripts.

Benefits:

• Collection expressions
• Primary constructors
• Inline arrays
• Optional parameters in lambda expressions

2. System.Text.Json Default Using​

System.Text.Json namespace is now included in default usings for script mappings.

Before:

using System.Text.Json;
// ... then use JsonSerializer

After:

// JsonSerializer is available directly
var json = JsonSerializer.Serialize(data);

3. Automatic Cache Invalidation After Deploy​

Cache is now automatically cleared after each component deployment to ensure consistency.

Details:

• Re-initialize is triggered after every deploy operation
• Guarantees that cached definitions are refreshed
• Prevents stale cache issues after component updates

Configuration Updates​

Configuration for v0.0.31:

{
  "runtimeVersion": "0.0.31",
  "schemaVersion": "0.0.30",
  "componentVersion": "0.0.18"
}

Issues Referenced​

Features:

• #88 - Enhanced Error Handling System
• #202 - Implement GraphQL-Style Filtering for Instance Data
• #209 - Support "latest" String Value in References
• #238 - Direct Trigger Task for Parent Transition
• #272 - Add Filter Support to GetInstances Task
• #297 - Subflow State Change Event Implementation

Bug Fixes:

• #273 - Incorrect query string formatting for extensions parameter
• #274 - Correlation instanceId conflict handling
• #294 - Change merge behavior to replace arrays instead of merging
• #303 - Request size issue fix

Hotfixes:

• #268 - Publish component request times out for long-running operations
• #288 - Workflow Instance Busy/Active Status Management

Summary​

With this release:

• GetInstances Task for cross-workflow data fetching implemented
• Subflow State Change Events with EffectiveState field added
• Update Parent Data Transition for SubFlow-to-parent communication implemented
• GraphQL-style filtering for instance data added
• Flexible version resolution ("latest", Major, Major.Minor) in references added
• Enhanced Error Handling System (ErrorBoundary) with multi-level error boundaries
• HTTP request size limits increased
• Extension query string formatting fixed
• Array merge behavior changed to replace mode
• Correlation conflict handling improved with 409 response
• Instance Busy/Available status management implemented
• Init-service timeout configuration added
• Automatic cache invalidation after deploy added
• C# 12 script engine support added
• System.Text.Json added to default usings

Upgrade Path​

From v0.0.30 to v0.0.31:​

1. Update Runtime:

   git pull origin master
   

2. Update Configuration:

   {
     "runtimeVersion": "0.0.31",
     "schemaVersion": "0.0.31",
     "componentVersion": "0.0.18"
   }
   

3. (Optional) Configure Init-Service Timeouts: If you experience timeout issues during package publishing, configure the timeout environment variables:

   SERVER_TIMEOUT_MS: 1800000
   SERVER_KEEP_ALIVE_TIMEOUT_MS: 1800000
   SERVER_HEADERS_TIMEOUT_MS: 1810000
   

4. Database Migration: The EffectiveState field migration is applied automatically on startup.

vNext Runtime Platform Team
January 13, 2026

This release introduces significant new features including Service Discovery for cross-domain communication, Default Auto Transition support, "latest" version resolution, and a new Transition Schema API endpoint. Additionally, important bug fixes for subflow extensions, sequential task initialization, and publish component timeouts have been implemented.

⚠️ New Feature Alert: Service Discovery requires additional setup. See the Service Discovery section below for configuration details.

🚀 New Features​

1. Service Discovery for Cross-Domain Communication​

Implemented service discovery to enable communication between different domains.

Details:

• Domains can now discover and communicate with services in other domains
• Requires vnext-domain-discovery runtime installation (one per environment recommended)
• Core domain structure for service registration and discovery

Configuration: Add the following to your appsettings.json:

{
  "ServiceDiscovery": {
    "Enabled": false,
    "BaseUrl": "http://localhost:3001/api/v1",
    "ValidateSsl": false,
    "Domain": "discovery",
    "RegistryFlow": "domain-registration",
    "TimeoutSeconds": 30,
    "MaxRetryAttempts": 3,
    "RetryDelayMilliseconds": 1000,
    "CircuitBreakerFailureThreshold": 5,
    "CircuitBreakerTimeoutSeconds": 30,
    "DiscoveryCacheSeconds": 300,
    "DiscoveryEndpointTemplate": "/discovery/workflows/domain/instances/{0}/functions/data"
  }
}

⚠️ Note: Keep Service Discovery disabled in development environments. Enable it only in production environments.

Reference: #188 - Use Service Discovery Domain to Resolve URLs for Other Domains
Repository: vnext-domain-discovery

2. Default Auto Transition Support​

Added support for default transitions when no auto transition conditions are met.

Details:

• When no auto transition condition is satisfied, a default transition can now be triggered
• Uses triggerKind: 10 for default auto transition

Configuration:

{
  "triggerKind": 10
}

TriggerKind Values:

Reference: #199 - Implement Default Auto Transition for Failed Auto Transition Conditions

3. "Latest" Version Resolution in References​

Version references now support "latest" string value for automatic latest version resolution.

Details:

• Use "version": "latest" to automatically resolve to the newest version
• Major and Minor version references also resolve to the latest matching version

Examples:

{
  "key": "component-123",
  "version": "latest"
}

{
  "key": "component-123",
  "version": "1.1"
}

Reference: #209 - Support "latest" String Value in References for Latest Version Resolution

4. Transition Schema API Endpoint​

Added a new API endpoint to fetch transition schema content.

Details:

• New function definition to retrieve schema content defined on transitions
• Returns schema content if a transition schema definition exists

Endpoint:

GET /api/v1/{domain}/workflows/{workflow}/instances/{instance}/functions/schema?transitionKey={transition}

Reference: #216 - Add API Endpoint to Fetch Transition Schema

5. Idempotent Workflow Start​

Implemented idempotent behavior for workflow start requests with the same key.

Details:

• When starting a workflow with a key that already exists, the system now returns the existing instance information instead of an error
• Previous behavior: Returns 409 Conflict (InstanceAlreadyExists) error
• New behavior: Returns the existing instance's current status and ID

Previous Response (409 Error):

{
  "error": "InstanceAlreadyExists",
  "message": "An instance with key 'ORDER-123' already exists"
}

New Response (Idempotent):

{
  "id": "18075ad5-e5b2-4437-b884-21d733339113",
  "status": "A"
}

Benefits:

• Safe retry scenarios for network failures
• Clients can retrieve original start response on repeated calls
• No need for separate "check if exists" calls before starting

Reference: #200 - Implement Idempotent Workflow Start - Return Same Response for Repeated Calls with Same Key

🛠️ Bug Fixes​

1. Subflow Extension Invocation Bug​

Fixed an issue where extension calls within subflows were not returning correctly.

Problem:

• When a main flow transitioned to a subflow, the data endpoint only returned main flow data
• Extensions from subflows were not included in the response

Solution:

• Data endpoint now returns main flow data and appends subflow extensions to its response

Reference: #250 - Subflow içinde extension çağırımı

2. Logger Initialization in Sequential Tasks​

Fixed initialization errors occurring during sequential task execution.

Problem:

• Logger, Dapr, or Configuration initialization errors occurred during sequential task execution
• "Logger is not initialized" error in script output handler

Solution:

• Logger, Dapr, and Configuration initialization is now performed separately for each task in sequential execution

Reference: #265 - Script output handler failed – Logger is not initialized

3. Extension Response Mapping Bug​

Fixed response mapping issues in Extension HTTP task requests.

Problem:

• Response mapping in HTTP task requests within Extensions was not working correctly

Solution:

• Corrected the response mapping logic for HTTP task requests in Extensions

Reference: #239 - Extension Response Bug

🔥 Hotfixes​

1. Publish Component Timeout Fix​

Resolved timeout issues for long-running publish component operations.

Problem:

• Timeout inconsistency in init-service caused publish component requests to fail

Solution:

• Increased timeout duration to 10 minutes for publish component requests
• Server timeout configurations updated:

SERVER_TIMEOUT_MS: 1800000        # 30 minutes
SERVER_KEEP_ALIVE_TIMEOUT_MS: 1800000
SERVER_HEADERS_TIMEOUT_MS: 1810000

Reference: #268 - Publish component request times out for long-running operations
Documentation: Server Timeout Configuration

🔄 Improvements​

1. Transition Pipeline Locking Refactoring​

Refactored transition pipeline locking mechanism to resolve deadlock issues.

Changes:

• Scope-based lifecycle management for pipeline locking
• Sync dispatcher support added
• Local and remote gateway structure implemented
• Processes within the same domain use local gateway
• Cross-domain processes use remote gateway

Reference: #256 - Refactor Transition Pipeline Locking to Scope-Based Lifecycle with Sync Dispatcher Support

2. Schema Refactoring​

Fixed missing and incorrect schema definitions in vnext-schema repository.

Changes:

• Corrected missing schema definitions
• Fixed incorrect schema definitions
• Synchronized schema validator

Reference: vnext-schema #60 - Schema Refactoring: Fix Missing & Incorrect Definitions, Validator Sync

3. New Makefile Command: change-domain​

Added change-domain command to Makefile for quick domain configuration.

Usage:

make change-domain

This command allows you to quickly configure your development environment infrastructure for a specific domain.

🔧 Configuration Updates​

Configuration for v0.0.29:

{
  "runtimeVersion": "0.0.29",
  "schemaVersion": "0.0.29",
  "componentVersion": "0.0.18"
}

🧱 Issues Referenced​

Features:

• #188 - Use Service Discovery Domain to Resolve URLs for Other Domains
• #199 - Implement Default Auto Transition for Failed Auto Transition Conditions
• #200 - Implement Idempotent Workflow Start
• #209 - Support "latest" String Value in References for Latest Version Resolution
• #216 - Add API Endpoint to Fetch Transition Schema

Bug Fixes:

• #239 - Extension Response Bug
• #250 - Subflow içinde extension çağırımı
• #265 - Script output handler failed – Logger is not initialized

Hotfixes:

• #268 - Publish component request times out for long-running operations

Improvements:

• #256 - Refactor Transition Pipeline Locking to Scope-Based Lifecycle with Sync Dispatcher Support
• vnext-schema #60 - Schema Refactoring

🧠 Summary​

With this release: ✅ Service Discovery for cross-domain communication implemented
✅ Default Auto Transition support added
✅ "Latest" version resolution in references supported
✅ Transition Schema API endpoint added
✅ Idempotent workflow start behavior implemented
✅ Subflow extension invocation bug fixed
✅ Logger initialization in sequential tasks fixed
✅ Extension response mapping corrected
✅ Publish component timeout issues resolved
✅ Transition pipeline locking refactored with gateway support
✅ Schema definitions corrected and synchronized
✅ New change-domain Makefile command added

🔄 Upgrade Path​

From v0.0.28 to v0.0.29:​

1. Update Runtime:

   git pull origin master
   

2. Update Configuration:

   {
     "runtimeVersion": "0.0.29",
     "schemaVersion": "0.0.29",
     "componentVersion": "0.0.18"
   }
   

3. (Optional) Configure Service Discovery: If you want to enable cross-domain communication, add the Service Discovery configuration to your appsettings.json and set up the vnext-domain-discovery runtime.

vNext Runtime Platform Team
January 4, 2026

This release focuses on bug fixes and stability improvements. Key fixes include Extension response mapping, HttpTask status code handling, memory leak resolution in Roslyn, and init-service response improvements.

✅ No Breaking Changes: This release is fully backward compatible with v0.0.26. No migration steps required.

🛠️ Bug Fixes​

1. Extension Response Mapping Bug​

Fixed an issue where response mapping was not working correctly on Extension.

Problem:

• Response mapping on Extension was producing incorrect results

Solution:

• Fixed the response mapping logic to handle Extension responses correctly

Reference: #239 - Extension Response Bug

2. HttpTask StatusCode Override Bug​

Fixed an issue where status code values were being overwritten incorrectly in HttpTask and Dapr Service Invocations.

Problem:

• HttpTask was overriding status code 500 incorrectly
• Dapr Service Invocation status codes were also affected