#4936·hatchet

[BUG] sticky strategy (HARD/SOFT) silently disables worker-affinity labels

Author: ayush00gitCreated Sep 9, 2026Updated Sep 14, 2026

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.