We’ve been having an issue over the past few months where an in-progress Azure Pipelines run/build will end up with a single job stuck at queue priority 1 if a new run begins before it manages to work down the existing queued jobs. The job does eventually start and complete, but only once there are no other jobs in the queue for newer runs.

• The job that gets blocked isn’t consistent – can be different every time it occurs.
• Most noticeable in a particular .yaml pipeline that contains about 17 jobs of varying durations that can run in any order. This will regularly queue back to back for different pull requests.
• The same job in the subsequent run can complete before the original one starts.
• The job that’s blocked remains at queue priority 1, but realistically behaves like it’s at the end of the queue – all other jobs queued are 2 onwards and seem to take precedence.
• We have four self-hosted agents available to this pipeline.

Some screenshots of the run/queue states the last time it occurred below.

Run queue:
Run queue

Original run with blocked job at priority 1:
Original, blocked run

Newer run with no blocked jobs, all either running or starting from priority 2:
New, not blocked run

The blocked job showing the priority:
Priority 1 blocked job in question

I’ve had a bit of a search for the issue in particular, as well as a browse through recent pipeline/job related issues here, which didn’t turn up much.

I’ve reviewed the range of jobs in the .yaml pipeline and we don’t use any particular means to control the flow of the jobs – they should run in any order.

Since it’s a newish issue and my searches didn’t turn up much I thought I’d start here before considering whether a support plan is justified. Thanks!