Environment
Unraid OS Version:
7.2.3 (and likely earlier versions)
Are you using a reverse proxy?
No. Tested by accessing server directly.
Pre-submission Checklist
Issue Description
The notifications overview returns incorrect archive.total count. The counter shows the same number as unread.total, even when there are 0 archived notifications.
This happens because the legacy notification script writes notifications to both /unread/ and /archive/ directories, and the overview counter does not filter out these duplicates.
Steps to Reproduce
- Query the GraphQL API for notifications overview:
query {
notifications {
overview {
unread { total }
archive { total }
}
}
}
- Observe that archive.total equals unread.total (e.g., both show 13)
- Query the archive list:
query {
notifications {
list(filter: { type: ARCHIVE, offset: 0, limit: 100 }) {
id
}
}
}
- Observe that the list returns 0 items, contradicting the overview count
Expected Behavior
- archive.total should reflect the actual number of archived notifications
- If there are 13 unread and 0 archived, overview should show unread.total: 13 and archive.total: 0
Actual Behavior
- archive.total shows 13 (same as unread)
- But fetching the archive list returns 0 notifications
- The count and actual data are inconsistent
Additional Context
Root Cause (found in source code):
In api/src/unraid-api/graph/resolvers/notifications/notifications.service.ts:
The getNotifications() method correctly filters duplicates from archive (lines 557-563):
const unreads = new Set(await readdir(UNREAD));
files = await this.listFilesInFolder(ARCHIVE, (archives) => {
return archives.filter((file) => !unreads.has(file)); // Filters duplicates
});
However, the overview counters do NOT apply this same filtering:
- handleNotificationAdd() (lines 111-125) - increments archive counter without checking for duplicates
- recalculateOverview() (lines 155-193) - counts all files without filtering duplicates
Suggested Fix:
Apply the same duplicate filtering logic to the overview calculation:
// When calculating archive overview, exclude files that exist in unread
const unreads = new Set(await readdir(UNREAD));
const archiveFiles = (await readdir(ARCHIVE)).filter(f => !unreads.has(f));
The comment in the code mentions this is "a temporary measure" for legacy script compatibility, but the fix was only applied to getNotifications() and not to the overview counters.
Environment
Unraid OS Version:
7.2.3 (and likely earlier versions)
Are you using a reverse proxy?
No. Tested by accessing server directly.
Pre-submission Checklist
Issue Description
The notifications overview returns incorrect
archive.totalcount. The counter shows the same number asunread.total, even when there are 0 archived notifications.This happens because the legacy notification script writes notifications to both
/unread/and/archive/directories, and the overview counter does not filter out these duplicates.Steps to Reproduce
query {
notifications {
list(filter: { type: ARCHIVE, offset: 0, limit: 100 }) {
id
}
}
}
Expected Behavior
Actual Behavior
Additional Context
Root Cause (found in source code):
In api/src/unraid-api/graph/resolvers/notifications/notifications.service.ts:
The getNotifications() method correctly filters duplicates from archive (lines 557-563):
const unreads = new Set(await readdir(UNREAD));
files = await this.listFilesInFolder(ARCHIVE, (archives) => {
return archives.filter((file) => !unreads.has(file)); // Filters duplicates
});
However, the overview counters do NOT apply this same filtering:
Suggested Fix:
Apply the same duplicate filtering logic to the overview calculation:
// When calculating archive overview, exclude files that exist in unread
const unreads = new Set(await readdir(UNREAD));
const archiveFiles = (await readdir(ARCHIVE)).filter(f => !unreads.has(f));
The comment in the code mentions this is "a temporary measure" for legacy script compatibility, but the fix was only applied to getNotifications() and not to the overview counters.