Pending friend request in admin bar

[Ezd]

I currently have a pending friend request in the admin bar but not inside my profile.

I think this accident happened when I was accepting a friend request and the browser didn't complete loading before i refreshed the window. So now I have a pending friend request in the admin bar that I can't get rid of even through the friend has already been added to the friend list.

Maybe some sort of check can solve this...

(Tested on testbp.org)

[DJPaul]

Can anyone recreate this?

[johnjamesjacoby]

I do actually have this same issue, only on buddypress.org of all places. The friends component was falling out of sync and not deleting friend request notifications. The only way I can think to fix this is to do some check when the user logs in, to see if notifications match up? If not purge 'em? Otherwise we're running checks all the time, which will be costly.

I've been thinking we probably need our own login bootstrap for a while, so maybe this can be the start of that?

[DJPaul]

I don't think we need a bootstrap around the login. I'd like to see us resolve this issue, and investigate doing something more involved to the login process (if you think there's a reason) for 1.4.

[boonebgorges]

I would rather find the source of the problem than create a large bootstrap mechanism. Login bootstraps will only be minimally effective anyway, for folks who have persistent WP login cookies.

These notifications are supposed to be cleared when you look at your friend requests page with the URL param 'new'. If I could reproduce the problem on a local setup, I could investigate further. Here's a place to start: ​https://buddypress.trac.wordpress.org/browser/trunk/bp-friends/bp-friends-screens.php#L48

In any case, I would rather let this (IMO) minor annoyance pass to the next milestone rather than push in an overengineered workaround for this one.

[johnjamesjacoby]

Replying to DJPaul:

I'd like to see us resolve this issue, and investigate doing something more involved to the login process (if you think there's a reason) for 1.4.

I think the issue is long since been fixed. The rogue notifications are friendships that have already been accepted that were never removed.

Checking if the notification count matches the actual pending count on the related screens sounds fine, and it's something we'd want to open up to all notifications in the long term. Could be a simple function hooked into the screen loader.

[boonebgorges]

Could be a simple function hooked into the screen loader.

But it'd add yet another query to every page load, or at least every page load where the current user had at least one friend-request notification.

If you think the root issue is long since fixed (which I tend to agree with, though there is a depressing lack of evidence either way :) ) then we should just leave well enough alone. At most, we could consider doing a bulk check during the upgrade routine to make sure that these numbers match.

[DJPaul]

Let's make sure to test this in beta (situations such as upgrading with pending notification comments, etc) and we can re-open once we figure out how to recreate.