Update job list to server-side filtering where possible

[JoeColeman95]

Description

bk job list --queue test-queue --state running takes forever to return, or never. The queue filter already ran on the server but the state filter didn't, so pages came back unfiltered and running was applied locally while the pager kept asking for more until it had 100 matches. A queue with fewer running jobs than that walks its whole history and never stops.

organization.jobs takes state and clusterQueue together, so this just sends the state with the queue.

I left --since and --until alone because the server does those as DATE(jobs.created_at), which would be less accurate than what we do now.

--duration has no server side equivalent so is staying as a client side filter, so the queue pager now stops after 2000 jobs while a local filter is still throwing results away.

Changes

• Refreshed schema as it was drastically outdated
• Only wire change is the two $state additions
• No longer collapses ASSIGNED and ACCEPTED into scheduled, or CANCELING into canceled. That changes displayed output and it's needed, otherwise --state assigns returns rows and then filters them out.

Testing

• Tests have run locally (with go test ./...)
• Code is formatted (with go fmt ./...)

Disclosures / Credits

Tests were written by Amp, I previously traced this on a ticket from a customer and established the fix then.

[buildsworth-bk-app]

No concrete defects found. The new server/client filter split and 2,000-job truncation behavior change job-list execution and UX, so I’m leaving the final intent sanity-check to a human reviewer.

Want to dig deeper?

Paste this into your agent to explore the findings from this review's Buildkite build:

Download the buildsworth logs from build 13022, then answer my questions about the findings.

Install the reading-buildsworth-logs skill to run this.

About buildsworth

Model: gpt-5.6-sol with xhigh thinking.

How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.

Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. To let it approve, grant L2 approval by mentioning @buildsworth-bk (see L2 approval grant):

• L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
• L2 — Standard risk (new UI, additive API fields, refactors). Approved only with an L2 grant; otherwise comment-only.
• L3 — High risk (auth, migrations, payments, secrets, perf-critical paths). Human review always required.

[mitchbne]

Hello I don't have much context on this area of the code base. Would you be able to help me understand why we are doing these filters client side rather than server side?

[JoeColeman95]

Hey @mitchbne,

I wrote this a while back following a customer request and our REST and GraphQL API's never supported filtering by state or queue then. We're talking ~1 year ago now. I since noticed that we'd upgraded the edges available, so have opted to upgrade this here to provide this functionality server-side opposed to handling it client-side as it can be rather slow for customers that have a lot of builds/jobs.

The change here is off the back of upgrades to bk/bk following a PF push, which began from inefficiencies for cluster queue insights IIRC?

But tl;dr, we had this requested a while back, it wasn't supported via the API, now it is.

[tomowatt]

I saw 14K additions and 5k deletions and wondered was the entire CLI being re-written but then saw it was the GraphQL Schema and generated.go

[mitchbne]

I think we could do state fully server side (even if we don't have queue or build?). I wonder if we could also do duration server side too?

[JoeColeman95]

Both true but have some quite significant drawbacks I never really explained properly tbf.

Duration can't be server side here because there's no duration or startedAt filter on the jobs, there is createdAtFrom and createdAtTo, and finishedAt, but that'd resolve to the nearest day rather than hourly, for example.

State is doable, but I think the better trade off here is client side as the complexity of the query would result in someone being able to get about 2 pages per 5 mins of results before they hit the default limit (graph). I'm using REST here as it's the cheaper option, which would allow users to get about 50 pages per min of results w/ the client-side filter. REST just returns a lot more per request in the case of jobs.