Release v0.0.58

Overview

This release closes the gap in subflow fault handling: a faulted child now propagates through the parent's error boundary chain instead of leaving the parent stuck in Busy (#699). Function responses and wizard-state behavior are extended — acceptedStatusCodes are honored end-to-end so rawResponse=true endpoints can forward structured HTTP 400s, and wizard states resolve transition views first while reporting hasView in a loop-safe way (#697). A hotfix standardizes instance audit columns via a shared base model and fixes the async reserved-transition lock (#644). The runtime repository's own documentation was rebuilt into an architecture-first structure (#693), and vocabulary-aware runtime schema validation was added (PR #692). This bump also advances the component schema to 0.0.43.

---

Features

Subflow fault propagates through the parent error boundary chain (#699)

Previously, when a SubFlow instance faulted, the parent only recorded a passive "SubFlow faulted" incident. It did not apply the faulted child's output and did not evaluate its own error boundary — so a boundary transition defined on the parent state (or globally) never fired, and the parent was left hanging in Busy with no remediation path.

Now the parent reacts to a subflow fault exactly as it would to a local task failure. On InstanceSubFaultedEvent for an open correlation, the parent:

1. Completes the correlation and merges the child's LatestData via SubflowOutputMappingService — before boundary resolution, so the resolver (and any view rendered by the boundary transition) sees the child's last-known data.
2. Builds an ExecutionError from the child incident (preserving ErrorCode, ErrorLayer, StatusCode, Message, task key, faulted state).
3. Resolves against currentState.ErrorBoundary then workflow.ErrorBoundary via IErrorBoundaryResolver (task-level boundary is N/A for subflow faults).
4. Executes the resolution:

Boundary action	Parent behavior
Log / Ignore	Incident resolved; pipeline resumes at ClearBusyOnResumeStep (order 79)
Boundary transition set	Runs under the ErrorBoundary profile (AllowAutoChain = false, AllowSubFlow = false — prevents cascading subflow failures)
Abort (or no boundary anywhere)	Incident recorded with boundaryAction = Abort; parent instance faults

The incident always records the resolved boundaryAction / boundaryLevel for the audit trail. The flow is idempotent (a second delivery of the same event returns early) and reverts the correlation in a new unit of work on resume/transition failure so the inbox handler can retry safely. SubProcess (P) correlations remain fire-and-forget; only SubFlow (S) is affected.

Reference: issue #699, PR #700 — see also Error Handling.

Accepted-status raw responses + wizard-state behavior (#697)

1. Structured response forwarding via acceptedStatusCodes. Task acceptedStatusCodes are now mapped into execution bindings (HttpTaskBinding.AcceptedStatusCodes) and honored by HTTP, SOAP, Dapr-service, and remote-trigger invokers through a shared AcceptedStatusCodeMatcher (exact codes like 400 plus wildcards like 4xx / 40x). When a status matches:

• The invocation is treated as successful — response body, parsed data, headers, and status code are preserved.
• Function endpoints with rawResponse=true can forward the structured response (e.g. an HTTP 400 schema-validation body) to the client; rawResponse=false keeps the existing wrapped HTTP 200 behavior.
• ErrorBoundary is not triggered — an accepted status is a business-success response, not a failure.

This enables schema-driven validation forwarding from engine endpoints such as /workflows/.../instances/start.

2. Richer state responses + wizard view resolution. State function responses now include the current state type and a transition kind for every returned transition:

state transition · shared transition · cancel · exit · updateData · timeout

For a wizard state, view resolution prioritizes the transition view without causing client-side render loops:

Situation	state.hasView	transition.hasView
Available state transition has a transition view	true	false (intentional — prevents client polling loops)
No transition view, but state view exists	true	—
Neither view exists	false	—

The View function follows the same wizard resolution and returns the relevant view.

Reference: issue #697, PR #698 — see also Functions and the View Concept guide.

---

Fixes

Standardized audit columns + async reserved-transition lock (#644)

• Audit columns: standard audit fields (CreatedAt, CreatedBy, …) are now inherited from a shared base model instead of being defined per entity, removing inconsistency and duplication across instance tables. ORM mappings were refactored accordingly while preserving compatibility with the existing persistence and migration structure.
• Async reserved-transition lock: the same hotfix corrects the asynchronous reserved-transition lock in the execution path.

Reference: issue #644, PR #703

---

Documentation & Validation

• Runtime documentation rebuilt (#693): the burgan-tech/vnext repository's internal docs/ were restructured into an architecture-first layout (architecture, domain, runtime, contracts, specs), with legacy pages archived. This is documentation-only and does not change runtime behavior. (This affects the runtime repo's own docs, not this portal.) — PR #695.
• Vocabulary-aware runtime schema validation (#692): runtime schema validation now accounts for vocabulary, tightening component validation. — PR #692.

---

Configuration Updates

Configuration for v0.0.58:

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

Note: Schema version advances to 0.0.43 (from 0.0.42). Update @burgan-tech/vnext-schema in your domain project before validating against this runtime.

Container images: published at tag 0.0.58 under ghcr.io/burgan-tech/vnext/* (execution, orchestrator, init, inbox, outbox, db-migrator), Cosign-signed with SBOM + provenance.

---

Issues Referenced

• vnext #699 — Propagate subflow fault through the parent error boundary chain.
• vnext #697 — Extend function responses (accepted-status raw responses) and wizard-state behavior.
• vnext #693 — Rebuild vNext runtime documentation structure.
• vnext #644 — Standardize audit columns via a base model (+ async reserved-transition lock).

---

Summary

• Subflow faults now drive the parent's error boundary chain (output merge → resolve → Log/Ignore/transition/Abort); no more hanging Busy parents.
• Functions honor acceptedStatusCodes end-to-end; rawResponse=true forwards structured HTTP 400s without triggering ErrorBoundary.
• State responses expose transition kind and state type; wizard states resolve transition views first with loop-safe hasView.
• Audit columns standardized via a shared base model; async reserved-transition lock fixed.
• Schema advances to 0.0.43.

---

vNext Runtime Platform Team
Released June 1, 2026