#3304 - notifications.php mark read returns 500 error in specific conditions
| Identifier | #3304 |
|---|---|
| Issue type | Minor issue (breaks specific functionality) |
| Title | notifications.php mark read returns 500 error in specific conditions |
| Status | Completed |
| Handling member | Chris Graham |
| Addon | core_notifications |
| Description | data/notifications.php will return 500 internal server error when trying to mark periodic review notifications of items that were deleted as read.
This bug was specifically confirmed for periodic reviews of members. If I have a period review notification for one of my members, but I had deleted that member, attempting to mark the notification as read will cause AJAX to return a 500 error... the notification never gets marked read. |
| Steps to reproduce | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
If you have deleted a member, how is that member marking a notification read?
I don't believe we have a feature to mark a specific notification read either, only all notifications.
And that code is extremely simple, just two lines.
I'd also want to see the error message from the error log, or extracted from the browser network log.
2017-06-05 03:13:08 Error (my IP) 500 GET /data/notifications.php?type=poller&type=mark_all_read&max=5&time_barrier=null&forced_update=1&keep_session=3034d8a00bde2 HTTP/1.1 https://www.lovinity.org/start.htm Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Dragon/57.0.2987.93 Chrome/57.0.2987.88 Safari/537.36 108 K nginx SSL/TLS access
Composr has no error logs in this... and the web browser console simply spits out that this request returned a 500 error.
Basically what happens is the following: say if I have a user. This user has periodic reviews enabled on the account. I receive a web notification about reviewing this account, but I do not yet mark it as read. Instead, I delete the member account because it was inactive. Now that the member account that the periodic review notification points to is deleted, trying to mark that periodic review notification as read using "mark all read" fails with the 500 error. It is permanently in my notifications as unread.
If so, I still find it a bit odd that it throws a 500 instead of simply not doing anything.
"time_barrier=null" was the clue.
I'm not sure the exact trigger but I think my 18eabed5b commit is a fix.
I think maybe a JS error happened before the notification init finished, leading to time_barrier being null rather than the current timestamp, causing an error when Composr init read that parameter during the mark unread operation.