src/commands/moveToDelayed-12.lua:90

• New behavior allows fetching the next job as part of moveToDelayed (via ARGV[8]/ARGV[9] and fetchNextJob). There are tests for retrying with backoff, but none appear to assert that moveToFailed(..., fetchNext=true) returns valid next-job data (and that worker attribution like processedBy is set) when the retry path uses moveToDelayed. Adding a focused test here would help prevent regressions in the new fast-path.

src/commands/moveToDelayed-12.lua:88

• When fetchNextJob returns a next job, this script returns early without calling addDelayMarkerIfNeeded. That can leave the delayed marker unset for the job you just moved to the delayed ZSET, causing sleeping workers to miss the wakeup and potentially delay the retry until the next drainDelay poll. Ensure the delay marker is updated even when returning the fetched next job (e.g., call addDelayMarkerIfNeeded(markerKey, delayedKey) before the early return).
  src/commands/moveToDelayed-12.lua:88
• The type(result[1]) == "table" guard means you drop non-job fetchNextJob results (rate-limited, paused/maxed, or {0,0,0,nextTimestamp} when only delayed jobs exist). That prevents callers from updating limitUntil/delayUntil based on the combined script call and undermines the intended roundtrip savings. Consider returning result whenever it’s non-nil and let the client interpret the tuple (as moveToFinished does).