Skip to main content
GET
Get a merge queue's dispatch order

Authorizations

Authorization
string
header
required

An API key, sent as Authorization: Bearer <key>. An organization admin creates one in the Trunk app under Settings → Developer → API Keys and chooses the merge-queue permissions it holds; a key with none can read merge queues but change nothing. Those permissions scope merge queue only: every key can use the Flaky Tests and Dynamic CI endpoints, including their writes, whatever permissions it holds.

Path Parameters

id
string
required

The merge queue's id.

Example:

"xK9mP2nQ"

Response

The queue's dispatch order

The queue's dispatch order: what is testing, what is admitted and waiting, and what has not been admitted. Pull requests that are not ready are deliberately absent — they hold no position — and are readable through GET /v2/pull-requests/{id}.

mode
enum<string>
required

The engine a queue runs. queue tests entries in strict arrival order, one line. graph builds a dependency graph and may test entries speculatively in parallel, which merges faster but can require bisection to attribute a failure. Changing mode is a real conversion, not a flag flip — see mergeQueues.switchModes.

Available options:
queue,
graph
Example:

"queue"

queueState
enum<string>
required

The queue's lifecycle state. switchingModes is a transient conversion state during which config and mode writes are refused.

Available options:
running,
paused,
draining,
switchingModes
Example:

"running"

batchingEnabled
boolean
required

Batching is configured. When false every pull request forms its own predicted batch, and directlyAhead is empty throughout.

Example:

true

isolationResolved
boolean
required

False when an ISOLATE batching rule could apply to this queue. Resolving those costs one impacted-target lookup per pull request, so this read skips it — which can move an isolated pull request into an earlier predicted batch, and so earlier in pending, than the engine will actually consider it.

Example:

true

hasCycle
boolean
required

The queue's graph has a cycle and the engine fell back to a degraded ordering. directlyAhead and heldBy are empty, and a held pull request reports as schedulable.

Example:

false

batches
object[]
required

Batches that have a verification run, in dependency order — a batch appears after the batches it builds on, with bisections last. Not start order, and not all of them are still testing: read each batch's state.

Maximum array length: 10000
pending
object[]
required

Admitted pull requests, in the order the engine will consider them; held ones come after schedulable ones. A schedulable entry's index is the number of admitted, schedulable pull requests the engine will consider before it — with batching off that is exactly the index — but that is not a wait: see predictedBatch.

Maximum array length: 10000
awaitingAdmission
object[]
required

Pull requests past the engine's graph soft cap, which hold no position yet. Ordered by a DIFFERENT comparator than pending, so the two lists are not one sequence, and truncated — see awaitingAdmissionTotal.

Maximum array length: 10000
awaitingAdmissionTotal
integer
required

How many are awaiting admission in total. The engine truncates the list, so compare this with awaitingAdmission.length to detect it; read a specific pull request through GET /v2/pull-requests/{id} rather than scanning.

Example:

0