How-to guideApplies to: Unified engine deployments
A query result and a confirmed table write are different outputs. Some tasks return rows, some publish a table, and some only wait or perform an action.
Read query results
A SQL task can retain row output for dependent tasks and API access. Run and task pages focus on execution rather than showing a result grid. Use Workbench for interactive SQL or query a published destination table.
For retained task output, use these routes:
Read metadata before requesting data. The result response uses format: "arrow-ipc" and encoding: "base64", with a schema, batches, a continuation token, and a truncation flag. Decode the Arrow data with a compatible client; it is not a JSON array of row objects.
The result endpoint defaults to one batch per page. Use limit and pass the returned continuation_token for the next page. Paging reads the existing result rather than executing the task again. Results can expire while run history remains. A successful write-only task or sensor may have no tabular result.
For Your first workload, the expected row is order_count = 6, sales = 140. For the multi-task workflow, the final result has three category rows and two region rows.
Share results within a workflow
A result alias supplies retained rows to a dependent SQL task. It is not a permanent table, a variable shared across workers, or an alias available in another Workbench session.
Selective reruns need any required reused row results to remain available. Run success alone does not prove that the result still exists. Preview shows blocked reuse; see Selective reruns.
Confirm publication
For a write task, inspect the final task state and commit details. Where the connector provides them, these include the destination table, commit receipt, affected rows, and table version information.
Prepared files, a successful upstream query, or an accepted request are not enough to prove that publication completed. Query the intended destination using the same catalog and namespace after a confirmed commit.
Affected rows describe the reported write, not necessarily the total current table size. Append, overwrite, and MERGE have different effects.
Understand partial success
There is no single transaction across a workload’s tasks or a backfill’s windows. One publication can remain committed even if later work fails or is cancelled.
Reusing a write task in a selective rerun preserves that confirmed outcome. It does not read a frozen copy of the destination unless the query explicitly uses an available version or snapshot.
Handle an uncertain outcome
OutcomeUnknown means the engine cannot confirm the final result. It does not mean the write failed. Keep the original run, task, attempt, and submission identities. Inspect commit evidence and let recovery establish the outcome before starting a replacement write.
A lost browser response is also not proof that work was rejected. Retry the original submission when recovering that request. A fresh submission ID can create new work.
Cancellation does not roll back a confirmed commit. See Troubleshooting for choosing a safe next action.Last modified on November 4, 2026
