2026-01-06 16:58:03 +01:00

6.7 KiB

Raw Blame History

Log Analysis & Feedback Report

Date: 2026-01-01
Log File: log
Analysis Scope: Application startup, notifications, session management, API calls

🔴 Critical Issues

1. Excessive Session Callback Logging (HIGH PRIORITY)

Problem:

10+ session callbacks triggered in a short period
Each getServerSession() call triggers verbose logging
Logs show === SESSION CALLBACK START === and === SESSION CALLBACK END === repeatedly

Root Cause:

Every API route calls getServerSession(authOptions)
Root layout (app/layout.tsx) also calls it
Session callback has extensive logging (lines 407-415 in app/api/auth/options.ts)

Impact:

⚠️ Performance: Unnecessary logging overhead on every request
⚠️ Log Noise: Makes it hard to find actual issues
⚠️ Debugging: Difficult to identify real problems

Recommendation:

// In app/api/auth/options.ts, line 405-415
async session({ session, token }) {
  try {
    // Only log in development or when there's an error
    if (process.env.NODE_ENV === 'development' || token.error) {
      console.log('=== SESSION CALLBACK START ===');
      console.log('Token error:', token.error);
      // ... rest of logging
    }
    
    // Or use a debug flag
    const DEBUG_SESSION = process.env.DEBUG_SESSION === 'true';
    if (DEBUG_SESSION) {
      console.log('=== SESSION CALLBACK START ===');
      // ... logging
    }
    
    // ... rest of callback
  }
}

Priority: 🔴 HIGH - Should be fixed immediately

2. Missing markAsRead/markAllAsRead Logs

Problem:

No API calls to /api/notifications/[id]/read or /api/notifications/read-all in the log
User reported notification count not updating after marking as read

Possible Causes:

User didn't actually mark notifications as read during this log session
API calls are failing silently (network errors, CORS, etc.)
Client-side code isn't calling the API correctly
API routes aren't logging their calls

Investigation Steps:

Add logging to mark-as-read API routes:

// In app/api/notifications/[id]/read/route.ts
export async function POST(request: Request, context: { params: Promise<{ id: string }> }) {
  console.log('[NOTIFICATION_API] Mark as read called', { id: context.params?.id });
  // ... rest of code
}

Check browser console for client-side errors
Verify network tab shows the API calls being made
Test the mark-as-read functionality while monitoring logs

Priority: 🟡 MEDIUM - Needs investigation

✅ Positive Observations

1. Notification Service Working Correctly

✅ Service initialized properly
✅ Count fetched: 100 total, 66 unread
✅ List fetched: 20 notifications
✅ Caching working: Cached notification counts for user
✅ Leantime adapter functioning correctly

2. Infrastructure Healthy

✅ Redis connection successful
✅ Database queries working (Prisma)
✅ IMAP connection successful (633ms)
✅ External APIs responding (News, Leantime, Rocket.Chat)

3. Data Flow

✅ Session creation successful
✅ User authentication working
✅ Token refresh logic functioning
✅ OAuth token management working

📊 Performance Metrics from Log

Metric	Value	Status
Redis Connection	✅ Success	Good
IMAP Connection Time	633ms	Acceptable
Notification Count Fetch	✅ Success	Good
Notification List Fetch	✅ Success	Good
Session Callbacks	10+ in short period	⚠️ Too many
Database Queries	✅ Working	Good

🔧 Recommended Actions

Immediate (This Week)

Reduce Session Callback Logging
- Add environment-based conditional logging
- Only log errors or use DEBUG_SESSION flag
- File: app/api/auth/options.ts
Add Logging to Mark-as-Read Endpoints
- Add console.log to track when mark-as-read is called
- Log success/failure
- Files:
  - app/api/notifications/[id]/read/route.ts
  - app/api/notifications/read-all/route.ts
Test Notification Mark-as-Read Flow
- Monitor logs while marking notifications as read
- Verify API calls are being made
- Check if cache invalidation is working

Short Term (Next Sprint)

Implement Request Deduplication
- Use the request-deduplication utility
- Prevent duplicate API calls
- Already planned in unified refresh system
Add Performance Monitoring
- Track API call frequency
- Monitor session callback frequency
- Alert on excessive calls
Optimize Session Access
- Consider caching session data
- Reduce redundant getServerSession() calls
- Use session context where possible

🐛 Potential Issues Not Visible in Log

1. Client-Side Errors

Browser console errors not captured in server logs
Network request failures
React component errors

2. Cache Invalidation

No logs showing cache invalidation after mark-as-read
May need to verify invalidateCache() is being called

3. Race Conditions

Multiple simultaneous API calls
State update conflicts
Not visible in single-threaded log

📝 Log Patterns Analysis

Session Callback Pattern

=== SESSION CALLBACK START ===
Token error: undefined
Has accessToken: true
Has refreshToken: true
Token role: [...]
Token sub: 203cbc91-61ab-47a2-95d2-b5e1159327d7
Token email: a.tmiri@clm.foundation
...
✅ Session created successfully
=== SESSION CALLBACK END ===

Frequency: Every API call that uses getServerSession()

Recommendation: Reduce to error-only logging

Notification Service Pattern

[NOTIFICATION_SERVICE] getNotificationCount called for user ...
[LEANTIME_ADAPTER] getNotificationCount called for userId: ...
[LEANTIME_ADAPTER] Notification counts: { total: 100, unread: 66 }
[NOTIFICATION_SERVICE] Cached notification counts for user ...

Status: ✅ Working correctly

🎯 Next Steps

Immediate: Fix session callback logging (5 minutes)
Today: Add logging to mark-as-read endpoints (10 minutes)
This Week: Test notification mark-as-read flow end-to-end
Next Sprint: Implement unified refresh system (already planned)

📌 Summary

Overall Assessment: ✅ System is functioning correctly

Main Concerns:

Excessive logging causing performance overhead
Missing visibility into mark-as-read operations
Need to verify notification count update flow

Confidence Level: 🟢 HIGH - Core functionality working, minor optimizations needed

Generated: 2026-01-01
Analyst: AI Code Assistant
Next Review: After implementing fixes

6.7 KiB Raw Blame History