#4994 Forum notifications not working [ss728]
[forge:site-support:#728]
After the Sourceforge upgrade of the SymmetricDS project (https://sourceforge.net/p/symmetricds/discussion/), the ability to subscribe to posts was lost. Current subscriptions stopped working and the Subscribe button doesn't seem to do anything. Is there a fix avaiable?
and
Yeah, since our upgrade of the SymmetricDS project, around 9/13/2012, emails are not being received when new topics are posted to our forums. We've tried combinations of "subscribing" and "unsubscribing" to the individual forums, but no combination seems to work.
Prior to the upgrade, we reliably received email notifications whenever a post was replied to or a new post was created (assuming you weren't the one replying yourself). We have tried to various email addresses as well, so we don't think it's somehow spam-filter related.
Thanks!
As per [forge:site-support:#739], sburleig of the ion-dtn project is having trouble getting notifications as well. He's confirmed his subscriptions, and received my response to his support ticket.
Regards,
Chris Tsai, SourceForge.net Support
Created #230: [#4994] Forum notifications not working [ss728] (2cp)
Related
Tickets:
#4994We've explored that a bit, and was not able to reproduce exactly that problem, but here is some thoughts:
Notifications doesn't sent to the subscribers when moderation is enabled. Discussion app doesn't even send notifications to the admins about posts that require moderation (tracker app does).
Furthermore, notifications about such posts doesn't send even after they have passed the moderation.
I guess, we need to check if the projects, that having problem with this, has moderation enabled, maybe this is the case.
Closed #230. I'll create another one if that is the case, and needs to be fixed.
For what it's worth, I've noticed missing notifications for ticket comments as well, and this is on a tickets instance which doesn't have moderation enabled.
Originally by: manuelbi
We're having erratic behaviour of the code changes subscription. I pushed something to our git repo yesterday and I got a nice notification mail (outside of the commit hook). However, my team mate also pushed something a bit later, but I got no notification.
In general it seems the people who subscribed on the code page with the envelope icon sometimes get mails and sometimes do not get mails.
Have found some SMTP timeouts in the logs. Ops ticket to investigate https://trac.sdot.me/trac/siteops/ticket/53612
SMTP connection timeouts have not occurred in the past few days, after we tweaked a setting. Let's see if that helps, or if there still are issues with notification delivery.
Originally by: manuelbi
For completeness sake, could you check what happened to the notifications on the openMSX git code? We hardly got any although there were a few commits. (That's why we installed the post-commit hook, so you can check on the openmsx-commits mailinglist of the openmsx project which commits should have been notified for our project.)
openmsx project reports that notifications are still not being sent out on commit. Is someone still looking into this?
Originally by: manuelbi
To be clear: there have been more than a dozen of commits since my last post here, but I haven't received any of the notification mails on the 'openmsx' repository. The main one: https://sourceforge.net/p/openmsx/openmsx/ci/master/tree/ (and yes, I'm "subscribed to this tool"). A few days ago one of our devs also committed to another subproject, and I did get a notifcation from that one: https://sourceforge.net/p/openmsx/debugger/ci/master/tree/
Please help.
I see no SMTP failures since we changed the settings for that. Some miscellaneous
allura.tasks.mail_tasks.sendmailfailures, but none for openmsx. So the problem is not with the sendmail task.allura:cj/4994Fixed two race-condition-type bugs that could cause notification loss, and added more error handling and logging to catch any others that might be lurking.
I was able to consistently reproduce the queued-but-not-in-mongo race-condition by pushing commits to a small repo that nonetheless had ~ 500 branches. (The large number of branches created a lot of "Building commit graph" messages which seemed to consistently trigger the race condition.)