Results and errors - BlockX Docs

Read RPC status for admission and transport errors. Once a task executes, read its terminal state and TaskResult. The protobuf definitions are in api/grpc/worker/worker.proto.

Result fields

Field	Meaning
`state`	Task state on the enclosing response or update
`result.success`	Whether the task completed successfully
`result.execute_result.failure_code`	Execution failure classification
`result.execute_result.failure_message`	Human-readable failure detail
`result.execute_result.retryable`	Whether the execution failure is classified as retryable
`result.execute_result.plugin_results`	Per-plugin name, success, failure code, and JSON result bytes

WatchTasks updates also contain is_terminal. An unknown task is reported through the update’s error. Results are held for the configured retention window; the default RESULT_RETENTION_MS is 300000.

Writer results

Writer path	Result content
`ReturnValueHandler`	JSON array of collected outputs
Block-table block write	`written_rows`, `finish_time`
Block-table bundle write	`written_rows`, `finish_time`, `job_id`

Debug writes do not create a storage job. Statistics and task success do not replace storage readiness checks.

RPC errors

gRPC status	Typical meaning
`InvalidArgument`	Invalid request, configuration JSON, or unsupported handler
`ResourceExhausted`	No available execution capacity
`FailedPrecondition`	Invalid or expired slot
`Unavailable`	Service not ready or connection unavailable
`NotFound`	No task result at the selected Worker
`Aborted`	Reservation outcome uncertain

Execution failures

Code	Inspect
`BUILDER_FAILED`	Source data and input configuration
`CALL_FAILED`	Function, audit findings, EVM reads, and contract calls
`PLUGIN_FAILED`	Target schema, output configuration, and write outcome
`TIMED_OUT`	Execution duration and backend availability
`OUTPUT_BYTES_EXCEEDED`	Collected output size
`WATCH_DISCONNECTED`	Watch connection lifetime

Use the returned retryability classification together with write state. Repeating a terminal task identifier does not force re-execution; see failure handling.