#3304 - notifications.php mark read returns 500 error in specific conditions

This is a spacer post for a website comment topic. The content this topic relates to: #3304 - notifications.php mark read returns 500 error in specific conditions
By Guest posted
I don't follow.

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.
By Guest posted
Unfortunately, 500 internal errors are very vague and often do not contain helpful information, such as this case. This is all I have in logs:

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.

By Guest posted
Perhaps maybe periodic review notifications were not meant to get marked as read and are automatically read when taken care of in the content edit screen?

If so, I still find it a bit odd that it throws a 500 instead of simply not doing anything.
By Guest posted
It's a real bug, but most of the report isn't related.

"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.
0 guests and 0 members have recently viewed this.