Epic: HUMAN task stub implementation and correctness fixes

[nthmost-orkes]

Overview

Conductor OSS includes a minimal HUMAN task stub — the task starts IN_PROGRESS and waits indefinitely for an external system to update it. This is the correct behavior for OSS: it unblocks the workflow and lets any external system (ticketing, approval portal, etc.) drive task completion.

However, the current stub has correctness bugs that need fixing before the full enterprise-grade HUMAN task implementation can be backported from Orkes Conductor.

Goals

• Fix the current stub so it behaves correctly (no queue pollution, proper API error codes, searchable in UI)
• Establish a clean foundation for the full Orkes implementation to converge onto
• Not in scope: assignment chains, SLA windows, form templates, claim/release workflows (those belong in the full implementation)

Issues Tracked

Issue	Description	Priority
#795	Prevent HUMAN tasks from polluting the decider queue	High — CPU waste on every sweeper cycle
#783	Fix 200 OK response on update-by-refName with invalid workflowId/taskRef	Medium — silent data loss
#704	Add HUMAN task type to UI task type filter dropdown	Low — usability gap

Architecture Notes (Orkes Convergence)

The full enterprise HUMAN task in Orkes Conductor has:

• Assignment chains with SLA windows (PENDING → ASSIGNED → IN_PROGRESS → COMPLETED)
• Claim/release/skip/reassign REST endpoints (/api/human/tasks/...)
• PostgreSQL persistence table (human_task_v2) with JSONB and tsvector search
• UI form templates for task display
• State-change workflow triggers

The OSS stub in Human.java + HumanTaskMapper.java is intentionally simple. The convergence path is:

1. Fix correctness issues (this epic)
2. Port OrkesHuman.java state machine + service layer to OSS (future epic)
3. Add REST endpoints for HUMAN task management (future epic)
4. UI integration (future epic)

Acceptance Criteria

• Prevent HUMAN tasks from polluting the decider queue #795: Workflows blocked on HUMAN tasks are removed from the decider queue; re-queued on HUMAN task completion
• [BUG] Bad response code/body on api for update a task by ref name if invalid workflowId or task ref (update HUMAN TASK) #783: POST /api/tasks/{workflowId}/{taskRefName}/{status} returns 404 when workflowId or taskRefName is not found
• UI does not have HUMAN task type in select list #704: HUMAN appears in the UI task type filter dropdown alongside other system task types

[mikebski]

I would propose including this in the list of issues for this epic: #705