Issue number from 200 plus jumps to 900 plus then thousand

[Chee Lim]

Hi, we have a installed version of jira and green hooper. we also set up issue handler and mail fetch to accept issue submission.

last week, for some reason, the issue number from only 214, then jump to 936 then up to today 4647.

No issues were created between the numbers.

[Nic Brough -Adaptavist- · Accepted solution]

I suspect that you do have a swathe of "missing" issues created, and possibly deleted, but Greenhopper is not the best place to try to check this.

Greenhopper may not be showing you all the issues because of a view setting, so could you try the issue navigator in Jira? It's a lot more simple to debug. Try the simple JQL of "project = NS" - blunt and lengthy, but no need to check filters, etc.

If you still don't see the issues, then check the project "security scheme" to make sure there are no security levels that may be hiding the issues from you.

If you do genuinely have these large gaps, then you'll need to start looking at logs to see what's going on.

[Chee Lim]

Hi, I tried the search, and still see the same result. I also check security and no scheme is assigned. any other suggestion? and how to check the logs?

[Nic Brough -Adaptavist-]

Hmm, that's where it gets difficult. Holes in issue sequences happen in four ways

1. Issues are created and then deleted
2. Issues are created and then moved
3. Someone stops Jira, winds the issue key count forwards in the database and then restarts Jira
4. Someone uses a plugin to do the same as the line above (I'm not aware of any plugins that do that, but that's not to say there isn't one, or that someone has written one and used it on your installation. I think you can do it with the "script runner" as well, but I've not tried it)

As an admin, I'm assuming you are probably going to know about the second two possibilities - have a look through the plugin list and ask your fellow admins. I don't really know of many business cases for doing it those ways though.

The first two are a bit more difficult because Jira doesn't log them. You can try to test for them - try going directly to one of the missing issues (ie. http://yourjira/browse/NS-230). Three possibilities here

1. It will tell you it doesn't exist - the issue has been deleted
2. It will take you to another issue in another project - look at the history and you'll see it's been created in NS and then moved elsewhere
3. It will tell you that it doesn't exist - the issue was moved, and then deleted

As you can see, there's nothing helpful if they've been deleted - that's where you need to start looking at access logs - do you have Apache or another webserver in front of it? If not, then you can try the Jira logs and look for "delete" in them, but it's probably not logged.

[Deleted user]

We have experienced same issue and came over this in atlassian-jira.log:

Customer related info replaced with x's

atlassian-jira.log:2013-12-04 23:47:50,149 QuartzScheduler_Worker-1 ERROR anonymous Support Capmon [jira.emh.service.EnterpriseMessageHandlerImpl] Unhandled Exception occurred during processing (mail will be deleted (to stop re-processing) but forwarded), type=java.lang.Exception), location=com.javahollic.jira.emh.service.ProcessorRunner.runProcessor(ProcessorRunner.java:905). This may be a BUG: Failed to create issue in project [SD], reason: com.atlassian.jira.workflow.WorkflowException: org.ofbiz.core.entity.GenericEntityException: while inserting: [GenericEntity:Issue][summary,Cops connection alarm][status,1][votes,0][assignee,null][number,4308][security,null][resolutiondate,null][type,7][timespent,null][id,18377][reporter,xxxxxxx@xxx.xx][project,10132][environment,null][created,2013-12-04 23:47:50.136][updated,2013-12-04 23:47:50.136][workflowId,20377][description,== Created by JEMH via e-mail from: "Xxxx Xxxxxx " <xxxxxxx@xxx.xx> ==

Customer mail stay in support inbox and the following error also was found in the same log:

| |][priority,4][timeestimate,null][duedate,null][timeoriginalestimate,null][watches,0] (SQL Exception while executing the following:INSERT INTO jiraissue (ID, pkey, issuenum, PROJECT, REPORTER, ASSIGNEE, issuetype, SUMMARY, DESCRIPTION, ENVIRONMENT, PRIORITY, RESOLUTION, issuestatus, CREATED, UPDATED, DUEDATE, RESOLUTIONDATE, VOTES, WATCHES, TIMEORIGINALESTIMATE, TIMEESTIMATE, TIMESPENT, WORKFLOW_ID, SECURITY, FIXFOR, COMPONENT) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) (Incorrect string value: '\xE2\x88\x92 di...' for column 'DESCRIPTION' at row 1))

2013-12-09 10:41:56,155 QuartzScheduler_Worker-1 ERROR anonymous Support Capmon [jira.emh.service.EnterpriseMessageHandlerImpl] Failed: null

This issue with incorrect strings startet for our case after upgrading to JIRA 6.1.2, which also caused upgrade problems from old database to the new one.

So it looks like JIRA increase issue numbers despite insert fails.

[Nic Brough -Adaptavist-]

Yes, it's sort of assuming that the issue being created is valid, and the actual creation is failing after the increment.

I'm afraid there is something wroing in the configuration of your JEMH handler and it can't hadle your email. You'll need to sort that out.