Both public routes ship untested:
app/api/newsletter/route.ts has no route.test.ts
app/api/search/route.ts has no route.test.ts
Other routes do have them, so the pattern to follow already exists in the repo (app/api/posts/route.test.ts, app/api/teams/waitlist/route.test.ts).
Newsletter is the one that worries me. It has real branching that nothing exercises: a new subscriber, an address that already exists, an address that previously unsubscribed, and reuse of an existing unsubscribe_token. Any of those regressing is silent, and the failure mode is either a missing welcome email or a duplicate one.
This pairs with the two rate limiting issues, since those need tests anyway. Doing them together is less work than doing them separately.
Acceptance
Both public routes ship untested:
app/api/newsletter/route.tshas noroute.test.tsapp/api/search/route.tshas noroute.test.tsOther routes do have them, so the pattern to follow already exists in the repo (
app/api/posts/route.test.ts,app/api/teams/waitlist/route.test.ts).Newsletter is the one that worries me. It has real branching that nothing exercises: a new subscriber, an address that already exists, an address that previously unsubscribed, and reuse of an existing
unsubscribe_token. Any of those regressing is silent, and the failure mode is either a missing welcome email or a duplicate one.This pairs with the two rate limiting issues, since those need tests anyway. Doing them together is less work than doing them separately.
Acceptance
app/api/newsletter/route.test.tscovers new, existing, and previously unsubscribed addressesapp/api/search/route.test.tscovers the short-query early return and a normal queryvitest