Skip to main content

AxonFlow v7.2.1 Release Notes

v7.2.1 is a small patch that closes the last observability gaps in the HITL approval flow. The approver identity and timestamp were already being captured and persisted on the step row, and the approval queue entry's UUID was already being set on the gate evaluation — but both were being dropped on the way out of the API, which forced every caller (Portal, SDKs, custom integrations) to do a second round-trip through the audit log just to find out who approved a step.

No schema changes. No breaking changes. Callers that previously treated these fields as absent simply start seeing real values.

This release matters most if you are:

  • polling GET /api/v1/workflows/{id} to confirm an approval landed and wanting to know who acted
  • correlating a require_approval gate decision with its HITL queue row for Slack / PagerDuty routing, direct portal deep-links, or programmatic approval
  • operating the Enterprise Customer Portal and hit an ErrorBoundary crash when expanding a pending approval

Community — HITL approval metadata surfaced on workflow responses​

approved_by and approved_at on every step in GET /api/v1/workflows/{id}​

The StepInfo DTO used by the workflow-detail response was missing both fields. Callers polling the workflow endpoint for approval completion saw approval_status: "approved" but no approver identity and no approval timestamp.

Both fields were already being captured by ApproveStep and persisted on the WorkflowStep row — the DTO just wasn't copying them into the response. v7.2.1 closes that gap, so the Portal and SDK consumers now get the full provenance without a second round-trip to the audit log.

Example response (approved step):

{
  "step_id": "step-2",
  "approval_status": "approved",
  "approved_by": "[email protected]",
  "approved_at": "2026-04-21T14:32:18.452Z"
}

This matters for compliance workflows where the "who approved what, when" chain needs to be reconstructable from the workflow response alone — EU AI Act Article 14, SEBI AI/ML, MAS FEAT audits all ask this question, and routing through the audit log for every row was slow.

approval_id on StepGateResponse​

When a gate evaluation returns require_approval, the HITL adapter was already creating the approval queue entry and setting StepGateEvaluation.ApprovalID internally. But the API response struct didn't carry the field, so SDK clients never received the queue entry's UUID on the same response that reported the require_approval decision.

That broke a practical pattern: an agent that wants to post a Slack message "hey @fraud-team, approval needed at /approvals/<approval_id>" had no ID to include without a second lookup against the approvals listing endpoint.

v7.2.1 adds approval_id to the gate response:

{
  "decision": "require_approval",
  "step_id": "step-2",
  "approval_id": "app_318a270f-...",
  "approval_url": "/approvals/app_318a270f-...",
  "reason": "high-value transaction requires fraud-team review"
}

Now SDK clients can route the approval event downstream with the same correlation ID the portal displays — in Evaluation and Enterprise, programmatic approvers can call the workflow approval endpoint (POST /api/v1/workflows/{wf}/steps/{step}/approve) or the Enterprise-only HITL queue operations (POST /api/v1/hitl/queue/{approval_id}/approve) without an extra lookup.

See HITL Approval Gates for the full approval lifecycle and Workflow Control Plane for the gate response shape.

Enterprise — Customer Portal /approvals page no longer crashes​

The /approvals page was crashing on row-expand with React error #31 ("Objects are not valid as a React child"), dumping the reviewer into the ErrorBoundary fallback the moment they clicked to see a pending approval's detail panel.

Root cause was a TypeScript type-vs-backend mismatch. The PendingApproval.policies_matched field was declared as string[], but the /api/v1/workflows/approvals/pending endpoint actually returns an array of PolicyMatch objects:

interface PolicyMatch {
  policy_id: string;
  policy_name: string;
  action: string;
  risk_level: string;
  allow_override: boolean;
  policy_description: string;
}

React tried to render the object directly and threw. v7.2.1 makes the approvals page accept either shape (defensive union), extracts policy_name when given an object, surfaces policy_description as a tooltip on the matched-policy chip, and uses policy_id as the React key.

The fix ships with a regression test against the real response shape. If you were seeing Portal reviewers bounce into the error page the moment they clicked an approval, upgrade.

Upgrade checklist​

  1. Upgrade the platform to v7.2.1.
  2. If you were working around missing approver identity by doing a separate audit-log lookup, you can stop — the workflow response carries it now.
  3. If you poll gate responses for require_approval decisions and route them to Slack / PagerDuty / a custom approver UI, update your code to read approval_id directly off the gate response.
  4. Enterprise: upgrade the Customer Portal image to pick up the /approvals render fix. No data migration.

Next release​

  • v7.3.0 — first-class retry semantics and idempotency keys on the Workflow Control Plane. Every step-gate response now carries a retry_context object and an optional idempotency_key that pins a step to a business-level identifier.

Relationship to v7.2.0​

If you skipped the preceding release, start with v7.2.0 — the Bug Bash Bonanza — which hardens the Customer Portal HTTP surface, tightens tenant-scope enforcement on tenant-scoped endpoints, fixes MAP plan timeout handling, and adds require_approval as a valid override action.

Last updated on