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?