Task and call

​

Task input

{
  "task_id": "3f2b1c9e8a4d4c1e9b0a6f7e5d4c3b2a",
  "functionCallConfig": {
    "type": "InputsCallConfig",
    "config": {
      "function": "",
      "code": { "sourceCode": "def _(name):\n    return {\"message\": f\"hello, {name}\"}\n" },
      "callList": [["ct2"], ["blockx"]]
    }
  },
  "resultHandler": { "type": "ReturnValueHandler", "config": {} },
  "taskTimeoutMs": 30000
}

​

Call

• Calls are independent of each other and fully parallel, sharing the same read-only world state at a single point in time. Return order is completion order and is unrelated to the order of the call list.
• Within one task, calls with the same function and the same arguments execute only once (task-level result cache and singleflight).
• A single call allows bounded retries (DefaultMaxAttempts = 3); once any root call fails terminally, the whole task fails with CALL_FAILED (fastFail).
• A single call’s execution budget is CallDeadlineMs = 5000, counting only CPU and IO backend time, not queueing.
• Sub-function calls inside a user function (function.call) are calls too, but they do not enter outputs; they only hand their result back to the parent call. The nesting depth limit is MaxSubcallDepth = 8.

​

Outputs

​

External states

​

Result

{
  "success": true,
  "executeResult": {
    "retryable": false,
    "pluginResults": [
      {
        "pluginName": "ReturnValueHandler",
        "success": true,
        "result": [{ "message": "hello, ct2" }, { "message": "hello, blockx" }]
      }
    ]
  }
}

• It does not contain the return value of each call. Only ReturnValueHandler puts the whole outputs array into pluginResults[i].result; table-writing plugins return only statistics such as written_rows.
• Failures are expressed with failureCode and retryable. retryable=true means the Client can resubmit the same task; the framework itself does no task-level retry.
• Terminal results are kept on the Worker for ResultRetentionMs (default 300000) and then cleared. The Client subscribes to terminal states with the WatchTasks stream, or polls with GetTaskResult.

​

Invariants

• Task-centric: read caches, state sharing, and timeouts are all anchored to the task and released when the task ends.
• Single-Worker execution: a task runs on only one Worker; the Worker is unaware of the Coordinator and exposes only RequestTaskSlot and SubmitTask.
• Function versions are fixed: a code snapshot (taskCodeEpoch) is pinned when the task is activated, and all subsequent calls and sub-calls use that snapshot; hot code updates only affect new tasks.
• Idempotent: while the same task_id is RUNNING or its result is still within the retention window, a repeated SubmitTask returns the current state and does not execute again.
• No task-level automatic retry, no cancellation: the framework only provides timeouts; whether to resubmit is up to the Client, based on retryable.
• Admission errors do not enter TaskResult: an invalid slot, no free slot, invalid arguments, an unregistered resultHandler.type, and so on are all returned as a gRPC status; once a task enters RUNNING, every later failure converges to the FAILED terminal state.

​

Summary

• task = task_id + Call Builder config + optional Writer Plugin config + optional timeout; call = function + positional arguments.
• Calls are fully parallel, unordered, and deduplicable; outputs is a flat collection of return values.
• Externally there are only four states, ALLOCATED / RUNNING / SUCCEEDED / FAILED; failures are expressed with failureCode + retryable.
• The framework neither retries nor cancels tasks; the idempotency key is task_id.

• Task lifecycle: the end-to-end sequence, the slot state machine, and a quick reference for time semantics.
• Call Builder and Writer Plugin: the config shapes of functionCallConfig and resultHandler.
• Function code: what the code a call runs looks like.
• Submit a task: examples: submit a task with blockx-py or by calling gRPC directly.