Skip to content

task.transition blanket-rejects every target while a direct-execution attempt is live #4554

Description

@lsm

The direct-execution half of #4548. #4553 fixed the workflow-run half; this one is untouched.

rejectActiveDirectAttempt (space/operations/transition-task-admission.ts:69) is piped before decide in the transition-space-task pipeline, so a task started with Run rejects unsupported_status for every target — Mark Done, Block, Stop alike. The legacy spaceTask.update handler has no equivalent gate and writes the status.

Same shape of leak as the workflow case, different mechanism: stop_for_status is workflow-specific and is not the right teardown path here. The direct binding lives in task.cancel (see space/operations/cancel-task.ts), which fences a reserved attempt and returns a durable job acknowledgement.

Decision needed, matching what #4548 settled for workflow runs: a terminal write against a live direct attempt should tear the attempt down first, then write. That likely means routing through the direct-cancellation binding before the status write, rather than rejecting.

Blocks: the 4 web status-write call sites in SpaceTaskPane.tsx / TaskAuxiliaryPanel.tsx / PendingPostApprovalBanner.tsx, which can hit either a workflow run or a Run attempt and cannot move to task.transition until both are handled. #4547 was closed over exactly this.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions