feat(notification): notify followers when a bot publishes a post

[aquie00t]

The gap

I follow the typescript bot. TypeScript ships a release, the bot posts it, and nothing reaches me — the only way to find out is to open the feed and scroll.

NotificationType.NEW_POST is already in the enum, and Notification already has an isNewPost() helper and a message case for it. But nothing in the codebase ever creates one: CreatePostUseCase had no notification or realtime dependency at all. The skeleton was there; the fan-out was never written.

Scope: bot posts only

TECH_NEWS and SYSTEM_UPDATE notify followers. COMMUNITY does not.

The ~354 persona accounts that keep the feed from looking empty are also isBot and publish community posts; notifying every follower of every one of those would bury the releases people actually followed an account for. The production numbers say this costs almost nothing in coverage — of the last 50 posts, 49 were bot-authored and 1 was community.

Shape

The fan-out is its own use case (NotifyNewPostUseCase) rather than logic inside post creation, called after the post commits with its failure logged instead of thrown:

void this.notifyNewPostUseCase
    .execute({ postId: rawPost.id, authorId: input.authorId, postType: input.type })
    .catch((err: unknown) => {
        this.logger.error({ err, postId: rawPost.id }, "Failed to notify followers of a new post");
    });

The post is the thing worth keeping, so a notification problem must not surface as a failed request. That shape is also what makes the eventual queue migration a change of caller rather than a rewrite — today CreatePostUseCase calls it, tomorrow a worker does, and the use case cannot tell the difference. Tracked in #235.

Sizing that decision, from production: the largest bot has 102 followers, typescript has 3, and bots publish ~49 posts/day across 144 accounts (roughly one per bot every three days). A batched fan-out is ~2 queries plus one Redis publish per recipient — a queue today would be buying retry/dead-letter/worker-deployment overhead for a problem that does not exist yet.

Two deliberate deviations worth reviewing

createMany does not trim recipient history. create() runs a per-recipient 100-row trim after every insert (a findMany plus a deleteMany). Repeating that in a batch would make a fan-out 2N+1 queries and defeat the point. Age is already bounded by the notification purge job. If the 100 cap should be maintained, it belongs in that job as a bulk operation — noted, not done here.

getFollowerIds excludes soft-deleted followers, so an account awaiting purge cannot accumulate notifications it will never read.

Also

Removes a stray factory fragment that had been pasted inside the use-cases DI module docblock (use-cases.di.ts, lines 79-84) — harmless because it sat in a /** */, but it corrupted the module's documentation.

Verification

• pnpm build, pnpm lint, pnpm format:check — clean
• pnpm test:unit — 855/855
• Integration (follow + notification repositories) — 32/32, covering getFollowerIds direction, soft-delete exclusion, and createMany writing the NEW_POST fields and counting toward the unread badge
• E2E tests/e2e/notification/ — 29/29 and tests/e2e/post/ — 24/24

The new E2E walks the actual reported scenario end to end: a user follows the seeded bot, the bot publishes TECH_NEWS under its own token, and the notification appears with the right postId while the unread count rises. It also pins the negatives — a non-follower gets nothing, and a COMMUNITY post produces nothing. The fan-out is deliberately asynchronous, so the assertion polls rather than assuming it has landed by the time the post response returns.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HWgtHjp6QQe4A7WfJXNknR

[github-actions]

🎉 This PR is included in version 1.12.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀