New dropA new codebase every week — fresh repo, fresh bugsSee this week's

Add pagination to GET /v1/jobs — feature ticket · 10xDebuggable

enhancementintermediateP2internal/store/jobs.go, internal/api/jobs_handler.goLevel 2 · Implement a feature20 XP1–2 hours

Add pagination to GET /v1/jobs

Nobody has started this yet — be first.

Business impact

GET /v1/jobs today fetches and returns every single job in the system in one response, unbounded. That's fine for a demo with 3 seeded jobs; it's a real problem for any operator running chronos at scale with thousands of jobs -- every dashboard load, every polling script, every health check that touches this endpoint pays the cost of serializing and transferring the entire table, and that cost only grows. An unbounded list endpoint is a classic, easy-to-miss source of a production incident: it works fine for months and then one day the jobs table crosses a size threshold and the endpoint starts timing out or OOMing the process.

Problem

internal/api/jobs_handler.go's listJobs already parses ?limit= and ?offset= and calls s.jobs.ListPage(ctx, limit, offset) when either is present (defaulting to limit=50, offset=0 if only one is given). internal/store/jobs.go's ListPage is a placeholder that panics with "TODO(ticket-E3): ListPage not implemented".

Current behavior

GET /v1/jobs?limit=2&offset=1 returns HTTP 500 instead of 200.

Expected behavior

GET /v1/jobs?limit=20&offset=40 returns jobs 41-60 (ordered by id), so a client can page through the full set predictably. Omitting both limit and offset keeps today's "return everything" behavior.

Steps to reproduce

Run the server and call GET /v1/jobs?limit=2&offset=1.
Observe: HTTP 500 instead of a paginated 200 response.

Why this matters

This is standard offset-based pagination -- the same ORDER BY ... LIMIT ... OFFSET ... pattern already used elsewhere in this codebase (e.g. pkg/queue.ListByJob's LIMIT $2), just with an added OFFSET.

Suggested approach

Look at List in internal/store/jobs.go for the base query and ordering (ORDER BY id) to build on; ListPage needs the same query with LIMIT $1 OFFSET $2 appended.

Acceptance criteria

GET /v1/jobs?limit=2&offset=1 returns exactly 2 jobs, skipping the first one by id order
Results are ordered by id ascending, consistently, so paging through multiple requests doesn't skip or repeat rows
GET /v1/jobs with neither parameter is unaffected
go build ./..., go vet ./..., gofmt -l . stay clean

Verification

TEST_DATABASE_URL="postgresql://chronos:chronos@localhost:5432/chronos?sslmode=disable" go test ./tickets/tests/... -run TestTicket09 -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b feat/list-jobs-pagination

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin feat/list-jobs-pagination

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Chronos — Distributed Cron Scheduler

A "cron-as-a-service" job scheduler backed entirely by Postgres -- SKIP LOCKED leasing and advisory-lock leader election, no etcd/ZooKeeper/Consul -- twenty ways the coordination quietly breaks.

Fork on GitHub

Download

Setup

Chronos — Distributed Cron Scheduler

git clone <your-fork>
cd GolangDevTraining/chronos
docker compose up --build   # postgres + two app replicas + adminer, hot-reloading on save

Two replicas run on () and (), both against the same database; Adminer is at . Verify with and .

http://localhost:8081

app-1

http://localhost:8082

app-2

http://localhost:8090

curl localhost:8081/healthz

curl localhost:8081/readyz

export TEST_DATABASE_URL="postgresql://chronos:chronos@localhost:5432/chronos?sslmode=disable"
go test ./tickets/tests/... -run TestTicket08 -v   # a single ticket
./tickets/run_tickets.sh                           # all 20, clean pass/fail summary