feat: notifications system, rate limiting, fix recipe visibility 404, follow race

Part of the social-feature backlog (follow, comments, reactions, ratings,
feed, threading) audited earlier — see conversation.

- notifications table: follow/comment/reply/reaction/rating events,
  replaces the fully-dead feed_items table (feed_item_type enum existed
  but had zero references anywhere in the codebase).
- Bell UI in the nav with unread badge, mark-all-read, 30s poll.
- Rate limiting on comment posting (20/min), follow/unfollow (30/min),
  and comment reactions (60/min) — previously unthrottled.
- /recipes/[id] queried by (id, authorId=session.user) only, so any
  recipe not owned by the viewer 404'd regardless of visibility.
  Widen the query to include public/unlisted recipes and gate the
  owner-only actions (edit, delete, version history, translate, AI
  content generation) behind an isOwner check.
- user_follows had no primary key/unique constraint, so the follow
  route's onConflictDoNothing() was a silent no-op — concurrent follow
  clicks could insert duplicate rows and inflate follower counts. Add
  a composite primary key on (follower_id, following_id).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Arnaud
2026-07-03 21:56:34 +02:00
parent e0e1ac49d9
commit 1abab17ca8
21 changed files with 11216 additions and 53 deletions
@@ -0,0 +1,21 @@
import { NextRequest, NextResponse } from "next/server";
import { db, notifications, eq, and } from "@epicure/db";
import { requireSession } from "@/lib/api-auth";
export async function POST(req: NextRequest) {
const { session, response } = await requireSession();
if (response) return response;
const body = (await req.json().catch(() => ({}))) as { id?: string };
await db
.update(notifications)
.set({ read: true })
.where(
body.id
? and(eq(notifications.userId, session!.user.id), eq(notifications.id, body.id))
: eq(notifications.userId, session!.user.id)
);
return NextResponse.json({ ok: true });
}