Kingrayhan/socket

[kingRayhan]

Problem

A single comment or reaction could produce many duplicate rows in notifications (e.g. 10+). That showed up as a flood of identical notifications in the UI.

Root cause

• persist-notification ran as one Inngest handler with the DB insert and Pusher publish in the same execution. Inngest retries failed runs. If anything failed after a successful insert (timeout, transient error, downstream issue), the whole handler ran again and inserted again.
• inngest.send had no stable event id, so duplicate or replayed events could not be deduplicated at the platform layer.

What changed

1. Durable steps in persistNotificationFn (src/lib/inngest.ts)

• step.run("insert-notification-row", …) — persists the notification row.
• step.run("publish-notification-realtime", …) — calls publishMessage for notification.new.

Completed steps are not re-executed on retry, so a retry after a partial failure does not insert duplicate notification rows.

Steps return small result objects (success / error info) for clearer runs in the Inngest UI.

2. Stable Inngest event IDs (src/backend/services/comment.action.ts, reaction.actions.ts)

• Comments: id: notif:comment:{commentId} — commentId is the same UUID used for the comment row (input.comment_id ?? random).
• Reactions: id: notif:reaction:{reactionId} — explicit reactionId generated before insert and stored on the new reaction row.

Aligns each app/notification.requested send with one logical notification and supports Inngest’s idempotent event processing when the same id is seen again.

3. Reaction row IDs (src/backend/models/domain-models.ts, reaction.actions.ts)

• Optional id?: string on Reaction so inserts can set a known UUID for correlation with the notification event id.

4. publishMessage (src/lib/pusher/pusher.server.ts)

• await pusherServer.trigger(…) inside try/catch so publishing is a real async operation; broker failures are logged and do not throw through callers that must stay best-effort.

5. Comment mutations (comment.action.ts)

• await publishMessage(…) for comment create/update/delete so the server action’s async boundary matches the Pusher call (consistent with the above).

How to verify

1. Add a comment or reaction as a user who is not the resource owner; the owner should see one new notification.
2. In Inngest, open a persist-notification run: you should see two steps (insert, publish) and no duplicate inserts on retries.
3. Re-send the same logical event id (if testing): duplicate delivery should be suppressed per Inngest idempotency rules.

Files touched

• src/lib/inngest.ts — step.run for insert + publish; structured step results.
• src/backend/services/comment.action.ts — stable comment id, notif:comment:… event id, await publishMessage.
• src/backend/services/reaction.actions.ts — reaction UUID + notif:reaction:… event id.
• src/backend/models/domain-models.ts — Reaction.id optional.
• src/lib/pusher/pusher.server.ts — await trigger, centralized error handling.