[BUG][NOTIFICATIONS] Eliminate split read state between Notification and User records

[Obiajulu-gif]

Summary

New notifications are written both to the Notification collection and to an embedded User.notifications array, but read/unread mutations update only the collection. Authentication responses and at least one dashboard page still consume the embedded array, so users can see stale unread counts indefinitely while the user document grows without bound.

Repository evidence

• app/api/notifications/route.ts:61-81 creates a Notification and separately appends an embedded copy to User.notifications.
• app/api/activity/route.ts:68-89 changes read state only in the Notification collection.
• app/api/auth/me/route.ts:18 returns the embedded array, and app/dashboard/driver/kyc/status/page.tsx:232 calculates its unread count.
• models/User.ts:184-187 stores the embedded array without a bound.

Scope

• Choose one authoritative notification/read-state store and migrate active consumers to it.
• Remove or boundedly retire embedded copies with a safe backfill/cleanup path.
• Ensure notification creation is not a non-atomic dual write.

Acceptance criteria

• All UI unread counts agree immediately after single-item and mark-all-read operations.
• Creating notifications no longer causes unbounded growth of the User document.
• Legacy embedded records are migrated or ignored deterministically without duplicating feed entries.

Tests

• Creation/read synchronization, mark-all-read, auth refresh, legacy-user migration, partial-write failure, and high-volume notification tests.

Non-goals

• Redesigning notification templates, delivery retries, or user preference policy.

[Chidi-Dev1]

I’d love the opportunity to resolve this issue. Kindly assign it to me.

[olathedev]

Hii maintainer, I would like to work on this issue. I have experience with TypeScript, APIs, and database-backed applications.

I understand the core issue is the split source of truth between Notification and User.notifications. I’d consolidate the read state into a single authoritative store, update the affected consumers, safely handle legacy embedded records, and add tests to prevent stale unread counts or duplicate data going forward.

[grantfox-oss]

🦊 GrantFox — @olathedev has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #200)
2. Your PR will be reviewed by the Chainmove maintainers

Good luck! Track your progress on GrantFox.