> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blockx.chaintable.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Execution semantics and results

> Distinguish task completion, write submission, and readable EVM-derived data.

Execution semantics define what you can infer from a BlockX result. Task acceptance, function completion, Writer Plugin success, and readable target data are separate observations in an EVM data workflow.

## Completion boundaries

| Observation | What it establishes | What to check next |
| - | - | - |
| `SubmitTask` returns `RUNNING` | The Worker accepted the task | Keep watching for a terminal result |
| `SUCCEEDED` with `ReturnValueHandler` | Collected outputs are available in the plugin result | Associate each output with its input |
| `SUCCEEDED` with a block write | The Writer Plugin completed its asynchronous write submission | Confirm the target block's storage completion and read conditions |
| `SUCCEEDED` with a bundle write | The BatchWrite submission completed and the writer returned a `job_id` | Confirm the BlockDB job and target data before downstream use |
| `FAILED` | The task reached a failure state | Inspect the failure code, message, and retryability |

A task's success does not establish a cross-table snapshot or advance every downstream consumer. The caller checks readiness for the data it will read next.

## Block and bundle writes

* The block path submits a write with `Sync: false`.
* The bundle path initializes a BatchWrite job, uploads its payload, and commits it. It returns after the commit response; it does not wait for the job's storage-side completion.
* Keep the output block or bundle aligned with the source computation.
* Debug table writes produce previews without persisting data.

## Watching and querying

| Operation | Role |
| - | - |
| `WatchTasks` | Sends current snapshots and terminal updates; also keeps running tasks attached |
| `GetTaskResult` | Queries the result held by the selected Worker |

When `WATCH_DISCONNECT_GRACE_MS` is positive, disconnecting the last Watch stream starts that grace period. If no stream reconnects, the task fails with `WATCH_DISCONNECTED`. The default `0` disables this behavior; tasks never watched are unaffected. A result query does not attach a Watch stream.

## Repetition and failure

* Repeating a submission to the same Worker while the task runs returns its current state.
* Within the result retention window, repeating that task identifier returns its terminal state.
* A new task identifier represents new work. Before resubmitting a write, check whether the previous operation took effect.
* A commit whose outcome is unknown is classified as non-retryable by the bundle writer. Inspect the write job rather than assuming no write occurred.

## Summary

* Read returned values directly; confirm storage conditions for written data.
* Maintain the task's Watch connection while it runs.
* Decide whether to repeat work using the result and write context together.

Continue reading:

* [Query results and handle failures](/guides/results-and-failures)
* [Results and errors reference](/reference/results-and-errors)
* [Backfill historical bundles](/guides/bundle-backfill)
* [Worker](/components/worker)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.