Monitoring, results, and debugging

A workflow run is a durable, auditable resource. This lesson collects the tools for observing runs, checking status, reading results, and drilling into individual tasks when something goes wrong. You have used some already; here they are together.

Status and Results

Helper	Input	Returns
getWeatherWorkflowResult	{ workflowId }	One run's status, result, and per-task summary.
getLatestWorkflowRunByUserType	{ workflowUserType }	The most recent run for a definition, with per-task detail.
pollWorkflowUntilComplete	{ workflowId, maxPolls?, pollIntervalMs? }	Polls until the run reaches a terminal state, then returns the final result.

getWeatherWorkflowResult calls IafWorkflowSvc.getWorkflowStatus(workflowId, ctx) and projects the useful fields:

{    workflowId, workflowDefId, name, status, result,    tasks: [ { id, name, type, sequenceno, status, result }, ... ],    createdAt, updatedAt, namespaces, userType}

The terminal states to test for are COMPLETED, FAILED, TERMINATED, and TIMED_OUT.

Deep Task-Level Inspection

When a run misbehaves, the summary is not enough, you need each task's inputs, outputs, and logs, including tasks nested inside composites. The demo provides debugAllWeatherWorkflowRuns for this. For every definition it fetches the most recent run(s) and hydrates every task via getTaskById and getTaskLogsById, recursing into FORK_JOIN, DO_WHILE, and SWITCH children.

You can run the debugAllWeatherWorkflowRuns script with input (all optional):

{ maxRunsPerDef: 1, userTypes: ["weather_workflow_polling_static"], logsPageSize: 200 }

For each run it produces a per-task tree plus a summary that makes anomalies pop:

summary: {    total,    byStatus,           // e.g. { COMPLETED: 4 }    emptyScriptOutputs, // task names whose scriptOutput has empty arrays    failedTasks         // task names in FAILED status}

Inspecting Composite Tasks

Composite tasks nest their children under different keys at runtime (_forkTasks, _loopOverTasks, _decisionCases), and some are also reachable through the getLoopOverTasks endpoint. debugAllWeatherWorkflowRuns probes both and de-duplicates, so you see the full subtree regardless of task type. If nothing is discovered for a composite, it returns the raw task response so you can inspect whatever the server did return.

A Practical Debugging Routine

1. getLatestWorkflowRunByUserType (is the workflow COMPLETED, or FAILED?)
2. If not clean, debugAllWeatherWorkflowRuns scoped to that one _userType. Read the summary's failedTasks and emptyScriptOutputs.
3. Open the offending task's inputParams and output: did a binding resolve to what you expected? An empty array or a missing field usually points at a binding path or an upstream script returning the wrong shape.
4. Fix the definition or the script, re-run the single creator, and run again.

Because every run is fully audited, this loop is almost always enough to localise a problem to a specific task and a specific binding.

---