A2A · TASK CONTROL ROOM
Task lifecycle: rejection versus execution failure
Interrupt a task, supply what it needs, and follow the actual state and artifact changes.
Your experiment
Compare rejection before execution with a failure at unit 3. Does either produce a final artifact? Can either terminal task be resumed?
Use Step to inspect a transition. The simulation pauses when it needs input or authorization; supply the requested action, then Play to resume.
Final artifact
State and action trace
Offline task-state teaching model, not an A2A server. Work units and active-time durations are illustrative. Waiting is excluded from active time; the view is deliberately paused during interruptions. Input/auth interruptions can resume the same task. Completed, failed, canceled and rejected tasks are terminal; follow-ups use a new task ID. Cancellation acceptance is a model switch, not a universal server guarantee. No credentials, external services or real artifacts are used. Official task lifecycle reference.
Rejection and failure happen at different boundaries
Enable Reject before execution and inspect zero completed units with no final artifact. Disable rejection and fail during unit three: two units can complete before the task becomes failed. Neither terminal state resumes through Supply clarification or Authorize. Create a follow-up and compare identifiers to see a new task rather than a retry inside the old one. The work units are synthetic, so this distinction explains state and artifact semantics without claiming that already-completed external effects were rolled back.
Configure a fresh task
Work units chooses the amount of illustrative work. Seconds per unit controls active processing duration, not real compute performance. Require input before unit and Require authorization before unit select different interruption gates; zero disables a gate, and a number above the work-unit count is never reached. Fail during unit makes that unit terminally fail without counting it as completed. Reject before execution refuses the submitted task before any work. Every configuration change creates a fresh experiment rather than editing the existing task in place.
Act on the current state
Supply clarification is enabled only for input-required; Authorize is enabled only for auth-required. Neither button supplies the other missing condition. Request cancellation asks the simulated worker to stop. Worker accepts cancellation controls whether it agrees; refusal leaves work active. A cancelled task has no final artifact even if some units finished. New follow-up task is available only after a terminal state and creates a new task identifier within the same context. Completed, failed, canceled and rejected are terminal; the control does not resume them.
Inspect time, identity and history
Play scales the configured active path to a minute of inspection. Waiting for clarification or authorization pauses progress and requires an explicit action before Play resumes. Pause holds the view; Step advances one active second, not one inspection second. Restart experiment resets the current configuration. Speed changes playback rate without changing task logic. Recorded state seeks through states already visited; resuming an earlier state discards its later branch. Follow-up begins a separate history. Inspect the task ID, context ID, completed units, final artifact and action trace together. This in-memory state machine has no durable checkpoint, remote worker, real authorization credential, network reconnect or external side effect.