[GH-ISSUE #56] Implement Notification History Functionality #26

New issue

Open

opened 2026-10-15 13:01:41 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 13:01:41 +00:00

Owner

Originally created by @salty2011 on GitHub (Jul 21, 2025).
Original GitHub issue: https://github.com/games-on-whales/wolfmanager/issues/56

Description

The notification history feature in the top menu bar is currently implemented as a visual placeholder only. The UI elements are present but the actual notification system and history tracking functionality needs to be implemented.

Current State

✅ Notification icon exists in the top menu bar
✅ Visual placeholder/dropdown is present
❌ No actual notification data is displayed
❌ No notification history tracking
❌ No notification system backend

Requirements

Backend Implementation

Create notification data model/schema
Implement notification storage system
Create API endpoints for notification management:
- GET /api/notifications (retrieve user notifications)
- POST /api/notifications (create new notification)
- PATCH /api/notifications/{id} (mark as read/unread)
- DELETE /api/notifications/{id} (remove notification)

Frontend Implementation

Replace placeholder with actual notification list
Implement notification types (info, warning, error, success)
Add notification timestamps and formatting
Implement mark as read/unread functionality
Add notification badges/counters for unread items
Implement real-time notification updates

Notification Sources

System events (container status changes, errors)
Client connection events (pairing, disconnection)
Task completion notifications
System maintenance notifications
Security alerts

UI/UX Features

Notification grouping by type or date
Clear all notifications option
Notification settings/preferences
Real-time notifications (toast/popup)
Notification sound/visual indicators

Technical Considerations

Integration with existing SSE event system for real-time updates
Database schema design for notification persistence
User-specific notification filtering
Notification retention policies (auto-cleanup old notifications)
Performance considerations for large notification histories

Acceptance Criteria

Users can view their notification history in the top menu dropdown
Notifications display with appropriate icons, timestamps, and content
Users can mark notifications as read/unread
Unread notification count is displayed in the menu bar
New notifications appear in real-time without page refresh
Notification system integrates with existing system events

Priority

Medium - Improves user experience but not critical for core functionality

Dependencies

Existing SSE event system
Database schema updates
UI component library

Originally created by @salty2011 on GitHub (Jul 21, 2025). Original GitHub issue: https://github.com/games-on-whales/wolfmanager/issues/56 ## Description The notification history feature in the top menu bar is currently implemented as a visual placeholder only. The UI elements are present but the actual notification system and history tracking functionality needs to be implemented. ## Current State - ✅ Notification icon exists in the top menu bar - ✅ Visual placeholder/dropdown is present - ❌ No actual notification data is displayed - ❌ No notification history tracking - ❌ No notification system backend ## Requirements ### Backend Implementation - [ ] Create notification data model/schema - [ ] Implement notification storage system - [ ] Create API endpoints for notification management: - GET /api/notifications (retrieve user notifications) - POST /api/notifications (create new notification) - PATCH /api/notifications/{id} (mark as read/unread) - DELETE /api/notifications/{id} (remove notification) ### Frontend Implementation - [ ] Replace placeholder with actual notification list - [ ] Implement notification types (info, warning, error, success) - [ ] Add notification timestamps and formatting - [ ] Implement mark as read/unread functionality - [ ] Add notification badges/counters for unread items - [ ] Implement real-time notification updates ### Notification Sources - [ ] System events (container status changes, errors) - [ ] Client connection events (pairing, disconnection) - [ ] Task completion notifications - [ ] System maintenance notifications - [ ] Security alerts ### UI/UX Features - [ ] Notification grouping by type or date - [ ] Clear all notifications option - [ ] Notification settings/preferences - [ ] Real-time notifications (toast/popup) - [ ] Notification sound/visual indicators ## Technical Considerations - Integration with existing SSE event system for real-time updates - Database schema design for notification persistence - User-specific notification filtering - Notification retention policies (auto-cleanup old notifications) - Performance considerations for large notification histories ## Acceptance Criteria - [ ] Users can view their notification history in the top menu dropdown - [ ] Notifications display with appropriate icons, timestamps, and content - [ ] Users can mark notifications as read/unread - [ ] Unread notification count is displayed in the menu bar - [ ] New notifications appear in real-time without page refresh - [ ] Notification system integrates with existing system events ## Priority Medium - Improves user experience but not critical for core functionality ## Dependencies - Existing SSE event system - Database schema updates - UI component library

bsakaguchi added the

enhancement

label

2026-10-15 13:01:41 +00:00

bsakaguchi commented

2026-10-15 13:01:41 +00:00

Author

Owner

@salty2011 commented on GitHub (Jul 31, 2025):

Status update: Notification History feature introduced an auth regression with Next.js request-scoped APIs

Observed error (from container logs):

Error: `cookies` was called outside a request scope. Read more: https://nextjs.org/docs/messages/next-dynamic-api-wrong-context
    at getExpectedRequestStore (.../request-async-storage.external.js:28:11)
    at u (/app/.next/server/chunks/2293.js:1:332330)
    at a (/app/.next/server/chunks/6306.js:25:18577)
    ... (repeat across app-route.runtime.prod.js and base-server)

Interpretation

Next.js dynamic APIs like cookies(), headers(), and draftMode() must be invoked within a valid request scope: only inside server components, route handlers, or server actions called during a request.
This error generally indicates that a server-only helper (or a codepath calling cookies()) is being executed in one of these contexts:
1. A client component or a hook that runs on the client.
2. A module imported by a client component that (transitively) imports server-only code.
3. A background interval/side-effect (e.g., notification polling/history) that triggers from outside a request lifecycle.
4. A RSC boundary leak where a server utility is referenced in a shared module consumed by both client and server.

Recent change likely implicated

"Notification history" feature wiring introduced background fetching/listeners and cross-cut imports. This may have pulled an auth/server helper (that reads cookies/session) into a client path.
Effects: Auth checks fail due to invalid access to cookies; redirects or guards may trigger inconsistently, causing login/protected-route failures.

Key areas to inspect in this repo

Auth glue:
- HOC: src/components/auth/with-auth.tsx
- Session provider: src/components/providers/session-provider.tsx
- NextAuth server helpers: src/lib/auth.ts
- Error boundary: src/components/auth/auth-error-boundary.tsx
Notifications:
- Hook/logic introduced for history or SSE: src/components/notifications/notification-hook.tsx
- Server routes or fetchers possibly using cookies() outside correct scope: under src/app/api/**

Immediate remediation checklist (safe changes)

Enforce server/client boundaries explicitly
- Mark server utilities with export const dynamic = 'force-dynamic' | 'auto' as needed in route handlers only.
- Ensure any function that calls cookies() resides exclusively in server files (e.g., src/lib/auth/server.ts) and is only imported by server components/route handlers. Avoid importing these from client components or shared modules.
Split modules
- If a shared utility both reads cookies and exports client-safe helpers, split into *.server.ts and *.client.ts (or separate files). Client code must not import the server one.
Client-only notification history
- Client components should fetch notification history via a fetch to an API route, not by calling server helpers directly.
- In the API route (server), read cookies/session and return data. In the client, use fetch('/api/...') or SWR/React Query; do not import server code.
Verify route handlers
- Ensure any calls to cookies() are inside app/api/**/route.ts functions or server actions (i.e., (req: NextRequest) => { cookies(); ... }). No top-level cookies() at module load time.
Audit imports for leakage
- Search for cookies(, headers( usage in non-route files and in any file imported by client components. Move those callers into server-only locations.

Diagnostics to capture

Which file/frame corresponds to /app/.next/server/chunks/2293.js and 6306.js in source (map via source map/stack traces in dev): likely an imported helper.
In dev, run pnpm dev and reproduce locally to capture a readable stack trace with file paths.
Confirm if any new export const runtime = 'edge' routes use cookies(): on edge runtime, use request.headers.get('cookie') patterns instead.

Follow-up plan

Refactor notification history data access: server-only cookie/session logic in API routes; client uses HTTP to fetch.
Validate that auth/session helpers in src/lib/auth.ts are not imported from client modules.
Once fixed, re-test login + protected routes and monitor for the error reappearing in logs.

@salty2011 commented on GitHub (Jul 31, 2025): Status update: Notification History feature introduced an auth regression with Next.js request-scoped APIs Observed error (from container logs): ``` Error: `cookies` was called outside a request scope. Read more: https://nextjs.org/docs/messages/next-dynamic-api-wrong-context at getExpectedRequestStore (.../request-async-storage.external.js:28:11) at u (/app/.next/server/chunks/2293.js:1:332330) at a (/app/.next/server/chunks/6306.js:25:18577) ... (repeat across app-route.runtime.prod.js and base-server) ``` Interpretation - Next.js dynamic APIs like `cookies()`, `headers()`, and `draftMode()` must be invoked within a valid request scope: only inside server components, route handlers, or server actions called during a request. - This error generally indicates that a server-only helper (or a codepath calling `cookies()`) is being executed in one of these contexts: 1) A client component or a hook that runs on the client. 2) A module imported by a client component that (transitively) imports server-only code. 3) A background interval/side-effect (e.g., notification polling/history) that triggers from outside a request lifecycle. 4) A RSC boundary leak where a server utility is referenced in a shared module consumed by both client and server. Recent change likely implicated - "Notification history" feature wiring introduced background fetching/listeners and cross-cut imports. This may have pulled an auth/server helper (that reads cookies/session) into a client path. - Effects: Auth checks fail due to invalid access to cookies; redirects or guards may trigger inconsistently, causing login/protected-route failures. Key areas to inspect in this repo - Auth glue: - HOC: [src/components/auth/with-auth.tsx](src/components/auth/with-auth.tsx:1) - Session provider: [src/components/providers/session-provider.tsx](src/components/providers/session-provider.tsx:1) - NextAuth server helpers: [src/lib/auth.ts](src/lib/auth.ts:1) - Error boundary: [src/components/auth/auth-error-boundary.tsx](src/components/auth/auth-error-boundary.tsx:1) - Notifications: - Hook/logic introduced for history or SSE: [src/components/notifications/notification-hook.tsx](src/components/notifications/notification-hook.tsx:1) - Server routes or fetchers possibly using cookies() outside correct scope: under [src/app/api/**](src/app/api/auth/[...nextauth]/route.ts:1) Immediate remediation checklist (safe changes) 1) Enforce server/client boundaries explicitly - Mark server utilities with `export const dynamic = 'force-dynamic' | 'auto'` as needed in route handlers only. - Ensure any function that calls `cookies()` resides exclusively in server files (e.g., `src/lib/auth/server.ts`) and is only imported by server components/route handlers. Avoid importing these from client components or shared modules. 2) Split modules - If a shared utility both reads cookies and exports client-safe helpers, split into `*.server.ts` and `*.client.ts` (or separate files). Client code must not import the server one. 3) Client-only notification history - Client components should fetch notification history via a fetch to an API route, not by calling server helpers directly. - In the API route (server), read cookies/session and return data. In the client, use `fetch('/api/...')` or SWR/React Query; do not import server code. 4) Verify route handlers - Ensure any calls to `cookies()` are inside `app/api/**/route.ts` functions or server actions (i.e., `(req: NextRequest) => { cookies(); ... }`). No top-level `cookies()` at module load time. 5) Audit imports for leakage - Search for `cookies(`, `headers(` usage in non-route files and in any file imported by client components. Move those callers into server-only locations. Diagnostics to capture - Which file/frame corresponds to `/app/.next/server/chunks/2293.js` and `6306.js` in source (map via source map/stack traces in dev): likely an imported helper. - In dev, run `pnpm dev` and reproduce locally to capture a readable stack trace with file paths. - Confirm if any new `export const runtime = 'edge'` routes use `cookies()`: on edge runtime, use `request.headers.get('cookie')` patterns instead. Follow-up plan - Refactor notification history data access: server-only cookie/session logic in API routes; client uses HTTP to fetch. - Validate that auth/session helpers in [src/lib/auth.ts](src/lib/auth.ts:1) are not imported from client modules. - Once fixed, re-test login + protected routes and monitor for the error reappearing in logs.

bsakaguchi referenced this issue

2026-10-15 13:01:55 +00:00

[PR #32] [MERGED] Fix/admin toggle privileges issue 26 #47