Restarting the service creates duplicate demo jobs every time

Nobody has started this yet — be first.

Business impact

seed.Run is called unconditionally on every boot. In a real deployment, instances restart routinely -- deploys, crashes, autoscaling, node maintenance. If seeding isn't idempotent, every restart adds another copy of every seeded job, each with its own cron schedule quietly firing against the same target_url. For the built-in demo jobs this is wasted load and a confusing job list; if this exact pattern were ever reused to seed real customer-configured jobs, it would mean duplicate charges, duplicate notifications, or duplicate side effects proportional to however many times the service has restarted -- a slow, silent, cumulative correctness bug.

Problem

seed.Run fetches the existing jobs into a byName lookup map, but the loop that creates jobs never consults it -- it calls jobs.Create for every demo unconditionally. Every call to seed.Run (i.e. every process restart) creates three brand-new demo-* jobs, regardless of how many already exist.

Current behavior

After calling seed.Run twice in a row (simulating one restart), job "demo-always-succeed" exists 2 times instead of exactly 1.

Expected behavior

seed.Run should create each demo job at most once, ever, no matter how many times it's called against the same database.

Steps to reproduce

Start against a fresh database; call seed.Run once.
Call seed.Run again (simulating a restart).
GET /v1/jobs (or query the jobs table directly) -- count jobs named "demo-flaky".

Why this matters

Idempotent seeding is what makes "restart-safe" mean anything. A seeding routine that isn't safe to call twice against the same state isn't really a seeding routine, it's an insert-on-every-boot routine that happens to look like seeding the first time.

Suggested approach

seed.Run already builds the byName map from the jobs that exist before this call. Look at what happened to the loop that's supposed to use it before deciding whether to create each job.

Acceptance criteria

Calling seed.Run twice in a row against the same database results in exactly one job per demo name, not two
Calling seed.Run against an empty database still creates all three demo jobs
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 TestTicket02 -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 fix/seed-duplicate-jobs

Fix it and commit

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

Push the branch

$git push -u origin fix/seed-duplicate-jobs

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 .