Issue Subscription sending emails unexpectedly and with void filter results

[Tayyab Bashir]

Hi,
I have a filter and I have subscribed to it on a daily basis.
I got two emails.

• At correct time and correct results
• At wrong time (extra and unexpected) with wrong results.

Following are the details from the wrong email:

----------------------------------------------------------------------------------------------------------------
Issue Subscription

Filter: assignee resolved in week (0 issues)

Subscriber: tbas
You may edit this subscription here.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira 
----------------------------------------------------------------------------------------------------------------

• Both emails are coming from the same server.
• I Don't have multiple subscriptions.

P.S. In any case, shouldn't the wrong email at least send the correct data? 

JIRA_ Subscription_ FW_Last_Update-2.eml

JIRA_ Subscription_ FW_Last_Update-1.eml

[Vasiliy Zverev · Accepted solution]

Second letter could be generated by some test JIRA instance. It happends when both instances uses the same mail server.

[Tayyab Bashir]

But both emails are coming from the same Url?

[Nic Brough -Adaptavist-]

Mail does not "come from a url", it comes from a user.

You usually create test systems by copying the production system.  When doing that, the usual procedure is "copy production, set the do-not-process-mail flags on the startup script, start it and change the base url to the test one".  It sounds like that has not been done to me, and as Vasiliy says, the test system is sending an extra mail, based on the fact that the mail server settings are the same and it's got a copy of your subscription, and it's likely that you have not changed anything in the last week in test...

[Vasiliy Zverev]

Different delivery time could be caused by different time on test instance server. Make sure that you do not have any test JIRA instances.

[Tayyab Bashir]

I've checked on all the test servers, the base urls are correct.
But in any case even if that procedure wasn't followed, the data is the same on both instances (production and test).
Even if the extra emails are coming from Test instance, shouldn't the mail at least show the correct result of filter? (instead it shows 0 issues).

Furthermore, we are having some problems with emails generated by bug watcher plugin, and we had to replicate the production server data multiple times on Test server during last week.
During all this we didn't disable the email because we were testing the email issue caused by bug watcher. 

Could this issue of issue subscription be related to bug watcher as well? 

[Nic Brough -Adaptavist-]

Er, you've pretty much confirmed that it probably is the test systems.  You're leaving them running, with production data, so they're sending subscription emails. 

Two things to try:

• Check your inbox - are you getting subscription mails from the test systems as well as the extra production ones?  If you do not appear to be getting the subscriptions from test, then it's almost certain that the extra ones you are seeing are from test.
• What happens if you shut down the test servers for a couple of days?  Do the extra emails stop?

For what it's worth, I don't think the bug watcher interacts directly with the subscriptions.  But it could be related.

[Vasiliy Zverev]

Also turn off putcomming mail on test instance: admin panel => system => mail => outgoing

(some steps could have other names in english because I use Russian version)

[Nic Brough -Adaptavist-]

The other option I've mentioned but not detailed - turn off the outgoing mail for a while.  See https://confluence.atlassian.com/jira/restoring-data-185729565.html#RestoringData-1.Disablingemailsending/receiving

[Tayyab Bashir]

Hi,

Nic, that was most helpful to check the inbox if I am getting the emails from Test or not (which I should usually get). 
Thank you both. 

I've disabled the outgoing email for Test server and I'll check the behavior for couple of days. 

I hope it resolves the issue. 

But I still don't get the point why the extra emails showed 0 issues, regardless of their origin.

[Vasiliy Zverev]

When you set up a subscription you have an option to send a mail when there is no issues. Check this option for subsriptions.

[Tayyab Bashir]

Yes that option is checked (meaning it would send email even if there are no issues present).
But the thing is, there were issues with that filter.

When I run that filter on test, it shows issues are present. So how come emails were sent with 0 issues. 

[Tayyab Bashir]

Hi,

The problem still persists. 
Every test system has their emails disabled.

I just got a subscription extra email at Wrong time with Zero Issues from the production server.
Even though the filter results in 19 issues.

Earlier that day I got email at correct schedule and with correct content. 

[Vasiliy Zverev]

Why are you sure that email was from production server. Do you have a lot of test  JIRA instances?

Try to find one with incorrect date&time on server. 

More one question: are there any condition into jql filter on data and/or time?

[Vasiliy Zverev]

More one version: you can have several filters with the same name. Try to find filters with name you get into email. 

[Nic Brough -Adaptavist-]

Yes, good point which makes me want to try another test - what happens if you delete your current subscription completely?

Also, when the "wrong" ones arrive, is there a pattern to the delivery?  Same time of day for example?  Always 4 hours behind the correct one?  Is it reliable (i.e. always happens)

[Tayyab Bashir]

Yes, I have one production server and multiple test instances. 
(different time zones: Test servers run 4 hours ahead of production) 

Yesterday I had disabled all the emails for test servers but still got extra emails. 

So I think someone else might have created a test instance on their local system and while they restored the production server's XML backup, they copied all the information of issue subscriptions and didn't change the base URL (so it appeared emails are coming from production)

We do need emails to be enabled for testing purposes on all Test servers.

But Is there a way while taking XML backup to just exclude the information of issue filter subscriptions? 

P.S. -Unfortunately I can't delete the subscription as I am not the only one subscribing to the filters. I can only delete on my end, but other people rely on those filter emails on daily basis. 

[Tayyab Bashir]

There are no conditions into jql filters on data. 
Despite everything, I dont think I should have been getting emails with 0 issues, because the date is the same everywhere. I manually ran the filters and every one of them resulted in issues.  

[Vasiliy Zverev]

Have checked that you do not have a filter with the same name?

[Tayyab Bashir]

Yes there is only 1 filter with that name on every instance.

[Tayyab Bashir]

The issue has been Identified

We took SQL dump of the production server database. 
And during testing on Test instances when we try to restore the mySQL dump it generates email to all the filter subscriptions. 
For example I have subscribed to 3 filters,
It generates 3 emails to my end, (1 for each filter).
If a filter has been subscribed twice or any number of times, It generates email that many times with that filter name.

[Vasiliy Zverev]

Here is a script to get all subsrciptions:

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.subscription.FilterSubscription
import com.atlassian.jira.issue.subscription.SubscriptionManager

StringBuilder result = new StringBuilder();
SubscriptionManager subscriptionManager = ComponentAccessor.getSubscriptionManager();
for(FilterSubscription subscription: subscriptionManager.getAllFilterSubscriptions()){
    result.append("{ " + subscription.getLastRunTime().toString() + " / " + subscription.getFilterId() + " }")
}

return result.toString()

It could be executed via Script Console provided by ScripRunner plugin. Try to find requared subsription based on it's last run time.

[Tayyab Bashir]

Capture.PNG

Error given on running the code.

[Vasiliy Zverev]

I think it will be easily to use this SQL:

Select
	filtersubscription.*
	, searchrequest.*
from
	filtersubscription
	left join	searchrequest	on	filtersubscription.FILTER_I_D = searchrequest.ID