Release Radar

Problem

You've been handed a small music-release service. Users follow artists; when an admin publishes an upcoming release, everyone following a credited artist should get a notification.

Two things are reported broken: notifications never arrive, and the unread badge shows counts that vanish when clicked. The scaffolding runs and some tests already pass — routes, auth, and models are in place. The failures are in the behavior.

This is a debugging arc, not a greenfield build. The seeded bugs are the two classic shapes: a contract violation (an endpoint returning the wrong status code) and a missing side effect (a state change that forgets its downstream work).

The API contract

Every endpoint requires an authenticated user. The status codes below are exact — the tests assert them.

Method	Path	Behavior
GET	/api/follows	Returns an array of the artist names the user follows
POST	/api/follows	Body artistName. 201 on success. 400 if missing or already followed
DELETE	/api/follows	Body artistName. 200 on success. 400 if missing, 404 if not currently followed
GET	/api/notifications	Supports an unreadOnly query flag
GET	/api/notifications/unread-count	Returns count
PATCH	/api/notifications/:id/read	200 and the updated notification. 404 if not found
POST	/api/admin/releases/:id/publish	Admin only. Moves an upcoming release to published and notifies followers of its credited artists

Phase 1 — Fix the follow contract

Following an artist you already follow currently succeeds. Unfollowing an artist you never followed also reports success. Both should be errors, and they are different errors: 400 for the duplicate, 404 for the missing.

Phase 2 — Deliver the notifications

Publishing a release correctly flips its status, and the endpoint returns a healthy-looking response. No notification is ever created. Each user following any credited artist should get one notification per release.

Watch the fan-out: a release crediting two artists that one user follows both of, and two separate releases, are different cases. Read the test names before deciding what "one notification" means.

Phase 3 — Make the badge honest

The unread count is wrong, and reading a notification doesn't reduce it. There are two candidate causes — the count query and the mark-as-read write — and they interact. Confirm which field each one touches before you change either.

Constraints

• Use the helpers the models already expose rather than hand-rolling equivalent queries.
• Don't change the test file or the API contract.
• Publishing an already-published release must not notify anyone a second time.