# Notification Issues - Analysis & Fixes

**Date**: 2026-01-01  
**Issues Reported**:
1. Count shows 66 messages, but only 10 are displayed
2. "Mark all as read" fails
3. Count doesn't update after marking as read

---

## 🔍 Issue Analysis

### Issue 1: Count vs Display Discrepancy

**Symptom**: 
- Badge shows: **66 unread notifications**
- Dropdown shows: **Only 10 notifications**

**Root Cause**:
1. **Count Logic**: `getNotificationCount()` calls `getNotifications(userId, 1, 100)` to count
   - Gets first 100 notifications from Leantime
   - Counts unread: 66
   - This is correct for the first 100 notifications

2. **Display Logic**: `getNotifications()` is called with `limit: 20` (default)
   - But only 10 are shown (possibly due to pagination or filtering)
   - This is a display/pagination issue

**The Problem**:
- If Leantime has more than 100 notifications total, the count will be inaccurate
- The count only reflects the first 100 notifications
- Display shows fewer notifications than the count

**Solution**:
- ✅ Added warning log when count reaches 100 (may have more)
- ⚠️ Consider using a dedicated count API if Leantime provides one
- ⚠️ Consider fetching all notifications for accurate count (may be slow)

---

### Issue 2: Mark All As Read Fails

**Symptom**: 
```
[NOTIFICATION_API] Mark all as read - Failed { userId: '...', duration: '197ms' }
```

**Root Cause**:
- Leantime API call is failing
- No detailed error logging to see why

**Solution Applied**:
- ✅ Added comprehensive error logging to `markAllAsRead()`:
  - Logs user email and Leantime user ID
  - Logs request body and API URL
  - Logs response status and body
  - Logs parsed response with error details
  - Logs exceptions with stack traces

**Next Steps**:
1. Test mark-all-as-read again
2. Check logs for detailed error information
3. Verify Leantime API method name is correct
4. Check if Leantime API requires different parameters

---

## 🔧 Fixes Applied

### 1. Enhanced Error Logging in `markAllAsRead`

**File**: `lib/services/notifications/leantime-adapter.ts`

**Changes**:
- Added detailed logging at each step
- Logs request details (body, URL)
- Logs response details (status, body, parsed data)
- Logs errors with full context
- Logs success/failure status

**Expected Log Output**:
```
[LEANTIME_ADAPTER] markAllAsRead called for ...
[LEANTIME_ADAPTER] markAllAsRead - User email: ...
[LEANTIME_ADAPTER] markAllAsRead - Leantime user ID: ...
[LEANTIME_ADAPTER] markAllAsRead - Request body: {...}
[LEANTIME_ADAPTER] markAllAsRead - API URL: ...
[LEANTIME_ADAPTER] markAllAsRead - Response status: 200
[LEANTIME_ADAPTER] markAllAsRead - Response body: {...}
[LEANTIME_ADAPTER] markAllAsRead - Parsed response: {...}
[LEANTIME_ADAPTER] markAllAsRead - Success: true/false
```

---

### 2. Enhanced Count Logging

**File**: `lib/services/notifications/leantime-adapter.ts`

**Changes**:
- Added warning when count reaches 100 (may have more notifications)
- Added read count to logging
- Added note about potential inaccuracy

---

## 🎯 Next Steps

### Immediate Testing

1. **Test Mark All As Read**
   - Click "Mark all as read"
   - Check logs for detailed error information
   - Look for `[LEANTIME_ADAPTER] markAllAsRead` entries

2. **Verify Count Accuracy**
   - Check if Leantime has more than 100 notifications
   - Verify count matches actual unread notifications
   - Check if count updates after marking as read

### Potential Issues to Check

1. **Leantime API Method Name**
   - Current: `leantime.rpc.Notifications.Notifications.markAllNotificationsAsRead`
   - Verify this is the correct method name in Leantime API

2. **Leantime API Parameters**
   - Current: `{ userId: leantimeUserId }`
   - May need additional parameters

3. **Leantime API Response Format**
   - Check if response format matches expected format
   - May need to handle different response structures

---

## 📊 Expected Behavior After Fixes

### Mark All As Read

**Success Case**:
```
[NOTIFICATION_API] Mark all as read endpoint called
[NOTIFICATION_API] Mark all as read - Processing { userId: '...', timestamp: '...' }
[LEANTIME_ADAPTER] markAllAsRead called for ...
[LEANTIME_ADAPTER] markAllAsRead - Success: true
[NOTIFICATION_API] Mark all as read - Success { userId: '...', duration: 'Xms' }
[NOTIFICATION_SERVICE] Invalidated notification caches for user ...
```

**Failure Case** (with detailed error):
```
[NOTIFICATION_API] Mark all as read endpoint called
[LEANTIME_ADAPTER] markAllAsRead called for ...
[LEANTIME_ADAPTER] markAllAsRead - Response status: 400
[LEANTIME_ADAPTER] markAllAsRead - Response body: {"error": {...}}
[LEANTIME_ADAPTER] markAllAsRead - API Error: {...}
[NOTIFICATION_API] Mark all as read - Failed { userId: '...', duration: 'Xms' }
```

---

## 🔍 Debugging Checklist

When testing, check logs for:

- [ ] `[LEANTIME_ADAPTER] markAllAsRead - User email:` (should show email)
- [ ] `[LEANTIME_ADAPTER] markAllAsRead - Leantime user ID:` (should show ID)
- [ ] `[LEANTIME_ADAPTER] markAllAsRead - Request body:` (should show JSON-RPC request)
- [ ] `[LEANTIME_ADAPTER] markAllAsRead - Response status:` (should be 200 for success)
- [ ] `[LEANTIME_ADAPTER] markAllAsRead - Response body:` (should show API response)
- [ ] `[LEANTIME_ADAPTER] markAllAsRead - Parsed response:` (should show result/error)
- [ ] `[LEANTIME_ADAPTER] markAllAsRead - Success:` (should be true/false)

---

## 📝 Summary

**Fixes Applied**:
1. ✅ Enhanced error logging in `markAllAsRead`
2. ✅ Enhanced count logging with warnings

**Next Actions**:
1. Test mark-all-as-read functionality
2. Review detailed error logs
3. Fix Leantime API call based on error details
4. Verify count accuracy

**Status**: ⏳ **AWAITING TESTING** - Enhanced logging will reveal the root cause

---

**Generated**: 2026-01-01