240 lines
6.7 KiB
Markdown
240 lines
6.7 KiB
Markdown
# 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**:
|
|
```typescript
|
|
// 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**:
|
|
1. User didn't actually mark notifications as read during this log session
|
|
2. API calls are failing silently (network errors, CORS, etc.)
|
|
3. Client-side code isn't calling the API correctly
|
|
4. API routes aren't logging their calls
|
|
|
|
**Investigation Steps**:
|
|
1. Add logging to mark-as-read API routes:
|
|
```typescript
|
|
// 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
|
|
}
|
|
```
|
|
|
|
2. Check browser console for client-side errors
|
|
3. Verify network tab shows the API calls being made
|
|
4. 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)
|
|
|
|
1. **Reduce Session Callback Logging**
|
|
- Add environment-based conditional logging
|
|
- Only log errors or use `DEBUG_SESSION` flag
|
|
- **File**: `app/api/auth/options.ts`
|
|
|
|
2. **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`
|
|
|
|
3. **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)
|
|
|
|
4. **Implement Request Deduplication**
|
|
- Use the `request-deduplication` utility
|
|
- Prevent duplicate API calls
|
|
- **Already planned in unified refresh system**
|
|
|
|
5. **Add Performance Monitoring**
|
|
- Track API call frequency
|
|
- Monitor session callback frequency
|
|
- Alert on excessive calls
|
|
|
|
6. **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
|
|
|
|
1. **Immediate**: Fix session callback logging (5 minutes)
|
|
2. **Today**: Add logging to mark-as-read endpoints (10 minutes)
|
|
3. **This Week**: Test notification mark-as-read flow end-to-end
|
|
4. **Next Sprint**: Implement unified refresh system (already planned)
|
|
|
|
---
|
|
|
|
## 📌 Summary
|
|
|
|
**Overall Assessment**: ✅ **System is functioning correctly**
|
|
|
|
**Main Concerns**:
|
|
1. Excessive logging causing performance overhead
|
|
2. Missing visibility into mark-as-read operations
|
|
3. 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
|
|
|