Enable Task status updates via POST requests

[declan-scale]

Updates

• Added POST requests to update tasks to a completed, terminated, timed_out, failed, or canceled state
• Added tests to support changes
• Only can interact with running tasks via the UI
• UI message rendering is not dependent on a user message

resolves AGX1-153

Greptile Summary

Adds dedicated POST endpoints to transition running tasks to terminal states (completed, failed, canceled, terminated, timed_out), replacing the need to use the generic PUT update endpoint for status changes. The backend uses an atomic UPDATE ... WHERE status = expected_status pattern to prevent race conditions on concurrent transitions, and publishes task_updated stream events so the UI receives real-time updates. The frontend disables the prompt input when a task reaches a terminal state and updates the message pairing logic to render agent-only message groups without a preceding user message.

• 5 new POST routes (/{task_id}/complete, /fail, /cancel, /terminate, /timeout) with optional reason body
• Atomic status transition at the repository layer prevents concurrent double-transitions
• UI prompt input disabled for terminal tasks with status-aware placeholder text
• Message rendering no longer requires a user message to start a pair — supports agent-initiated messages
• ESLint varsIgnorePattern fix from exact _ to prefix ^_
• Comprehensive unit and integration tests covering happy paths, blocked re-transitions, default reasons, and name-based lookups

Confidence Score: 4/5

This PR is safe to merge — the atomic update pattern is sound, test coverage is thorough, and the UI changes are well-scoped.

Score of 4 reflects a well-implemented feature with proper concurrency handling, comprehensive tests, and clean layer separation. Minor deduction for the pre-existing non-atomic update_mutable_fields_on_task method that now stands out as inconsistent with the new atomic pattern.

agentex/src/domain/use_cases/tasks_use_case.py — the existing update_mutable_fields_on_task method still uses a non-atomic read-then-write pattern, which contrasts with the new atomic transition approach.

Important Files Changed

Filename	Overview
agentex-ui/components/primary-content/prompt-input.tsx	Adds terminal-task detection to disable input and show status-aware placeholder; uses useMemo correctly with proper dependency arrays.
agentex-ui/components/task-messages/task-messages.tsx	Refactors message pairing to support agent-only message groups (no preceding user message), fixing rendering for status-update-only messages.
agentex-ui/eslint.config.js	Fixes varsIgnorePattern from exact _ to prefix ^_ to align with conventional unused-variable naming.
agentex-ui/lib/types.ts	Adds TaskStatusEnum with compile-time exhaustiveness check against the SDK Task status type.
agentex/src/api/routes/tasks.py	Adds 5 new POST endpoints for task status transitions with optional reason body and proper authorization.
agentex/src/api/schemas/tasks.py	Adds TaskStatusReasonRequest schema for the optional reason field on status transition endpoints.
agentex/src/domain/repositories/task_repository.py	Adds atomic transition_status method using UPDATE WHERE status = expected_status to prevent race conditions.
agentex/src/domain/services/task_service.py	Adds transition_task_status service method that wraps atomic repository call and publishes task_updated stream events.
agentex/src/domain/use_cases/tasks_use_case.py	Adds _transition_to_terminal with pre-flight validation and 5 public methods; handles concurrent modification via atomic update. Existing TODO remains unresolved.
agentex/tests/integration/api/tasks/test_tasks_api.py	Adds integration tests for all 5 new status endpoints covering happy path, default reason, and blocked re-transition.
agentex/tests/unit/use_cases/test_tasks_use_case.py	New comprehensive unit test file covering all status transitions, blocked transitions, default reasons, and metadata operations.

Sequence Diagram

sequenceDiagram
    participant Client as Client (UI/API)
    participant Router as FastAPI Route
    participant UseCase as TasksUseCase
    participant Service as AgentTaskService
    participant Repo as TaskRepository
    participant DB as PostgreSQL
    participant Redis as Redis Stream

    Client->>Router: POST /tasks/{id}/complete
    Router->>UseCase: complete_task(id, reason)
    UseCase->>Service: get_task(id)
    Service->>Repo: get(id)
    Repo->>DB: SELECT * FROM tasks WHERE id = ?
    DB-->>Repo: TaskORM
    Repo-->>Service: TaskEntity
    Service-->>UseCase: TaskEntity (status=RUNNING)
    UseCase->>UseCase: Validate status == RUNNING
    UseCase->>Service: transition_task_status(id, RUNNING, COMPLETED, reason)
    Service->>Repo: transition_status(id, RUNNING, COMPLETED, reason)
    Repo->>DB: UPDATE tasks SET status='COMPLETED' WHERE id=? AND status='RUNNING'
    DB-->>Repo: rowcount=1
    Repo->>DB: SELECT * FROM tasks WHERE id = ?
    DB-->>Repo: Updated TaskORM
    Repo-->>Service: TaskEntity (COMPLETED)
    Service->>Redis: publish task_updated event
    Redis-->>Service: OK
    Service-->>UseCase: TaskEntity (COMPLETED)
    UseCase-->>Router: TaskEntity
    Router-->>Client: 200 Task (COMPLETED)

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: agentex/src/domain/use_cases/tasks_use_case.py
Line: 99

Comment:
**TODO missing ticket reference**

This existing `# todo: make this a transaction?` comment should have a linked Linear ticket for tracking. Now that the new `_transition_to_terminal` method below demonstrates the correct atomic-update pattern via `transition_task_status`, this TODO is even more relevant — `update_mutable_fields_on_task` still uses a non-atomic read-then-write pattern that could overwrite concurrent metadata changes.

**Rule Used:** Create Linear tasks for TODO comments in code and ... ([source](https://app.greptile.com/review/custom-context?memory=6328a8b3-afcc-487b-aac4-241716e05e94))

**Learnt From**
[scaleapi/scaleapi#127117](https://github.com/scaleapi/scaleapi/pull/127117)

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (8): Last reviewed commit: "Add task status type to FE, null guard" | Re-trigger Greptile}

[danielmillerp]

any chance we can get some screenshots or video of behavior in UI?

[danielmillerp]

are these hittable from within the code? let's say from acp file or workflow file to be able to programitically stop running a task in the same way that we do with temporal?

[danielmillerp]

ideally we could do adk.task. etc etc same way we do adk.create message and all that

[danielmillerp]

changes in here seem fine ! mostly just other questions about expanding surface area and seeing behavior !

[declan-scale]

@danielmillerp

any chance we can get some screenshots or video of behavior in UI?

are these hittable from within the code? let's say from acp file or workflow file to be able to programitically stop running a task in the same way that we do with temporal?

They will be when we publish the updated SDK, I will be doing that after this merges.

[danielmillerp]

@danielmillerp

any chance we can get some screenshots or video of behavior in UI?

> are these hittable from within the code? let's say from acp file or workflow file to be able to programitically stop running a task in the same way that we do with temporal?

They will be when we publish the updated SDK, I will be doing that after this merges.

thank you sir !