[BUG] sticky strategy (HARD/SOFT) silently disables worker-affinity labels
Location: pkg/scheduling/v1/scheduler.go:1176-1202 (Scheduler.rankWorkerIds)
Root cause: rankWorkerIds switches on qi.Sticky. The case HARD: and case SOFT: arms never fall through to the label-affinity branch, which lives only under default:. So for any queue item with Sticky != NONE the desired labels (including Required=true labels) are never evaluated: every candidate worker gets rank 0 and is eligible.
Trigger: a task with sticky=HARD or SOFT and desired worker labels. The most common shape is the one the docs recommend (worker-affinity.mdx "Use extra care when using worker affinity with sticky assignment HARD ... set desired labels on the first task of the workflow"): the first task of a HARD-sticky workflow has DesiredWorkerID == nil and required labels.
Impact: required affinity is violated, the task is assigned to a worker that does not satisfy the required label (e.g. a non-GPU worker), and with HARD stickiness every subsequent task of the workflow is then pinned to that wrong worker. Weighted (non-required) labels are ignored too.
Source: hatchet-dev/hatchet