[openbotgit]

Problem

A job can be queued inside a run whose status is pending. GitHub reports a run that way while it waits to start, for example behind a concurrency group. QueuedJobs listed runs only with status=queued and status=in_progress, so the controller never saw such a job and it waited forever. Seen live: a decide job labelled self-hosted, railway-private, queued for 25+ minutes in a pending run while the pool was idle.

Fix

Also list status=pending runs. The job-level filter is unchanged: only queued jobs whose labels we can take are returned.

Tests

• New TestQueuedJobsIncludeQueuedJobsOfPendingRuns: failed before the fix, passes after.
• The ETag test now expects three conditional run-list reads.
• go test ./... and go vet are clean.

Cost: one extra conditional GET per repo per cycle, usually a 304 that doesn't count against the rate limit.

[openbotgit]

Review of 4282be3: ship.

• The fix is correct and minimal. QueuedJobs now also lists status=pending runs. The per-job filter is unchanged: status == "queued", not already seen, and labels we can take. So a runner is created only for a job GitHub has actually queued, never for a run that is merely pending.
• Duplicates are impossible. A job seen in more than one list is deduplicated by seen[j.ID].
• The test is right. TestQueuedJobsIncludeQueuedJobsOfPendingRuns serves the job only through the pending list and asserts it is returned.
• The ETag count is right. The 304 test now expects 4 conditional reads (three run lists and the jobs list), which matches the extra list.
• Cost. One more run-list request per repo per cycle. When nothing changed it returns 304, which does not count against the rate limit.
• Idle runners. A surplus idle runner, if GitHub assigns the job to another one, is reaped after IDLE_TTL_SECONDS (120 s), so there is no runaway.

Checks run on 4282be3, with CGO_ENABLED=0:

• go vet ./...: clean.
• go test ./...: all packages pass.

Not merged.