-
Bug
-
Resolution: Won't Fix
-
Medium (View bug fix roadmap)
-
None
-
4.1.2
-
Jira tomcat + mySql
-
4.01
-
Hello,
following the support request JSP-63263 it seems that the issue key is incremented even if the issue creation fails, this may produce big gaps in issue numbering. I reccomend to increment issue key only when issue creation is succeful.
How this may happen (according to what experienced in JSP-63263)
-We have jira configured with create or comment mail handler and "forwardTo" correctly set.
-At a point we had the smtp server down during three days, so no outgoing mail from Jira.
-During these period we have recived (at least) one incoming email producing an error at the issue creation time (related to a mySql DB ecoding issue)
-in this case normally Jira pops the email from the mailbox and sends a "EMAIL HANDLER: Error handling:" notification
-it seems that being impossible to send the notification (smtp down) jira leaves the incoming email in the mailbox and therefore it tries again one minute after to create the issue, incrementing each time the issue key (I suppose this because if you look at the main gap in JSP-63263 (MMSHD-5757 vs. MMSHD-632) you have ( 5757-632=5125 ) / 1440 (minutes per day) = 3.5 days. That is exactly the duration of the smtp sever downtime.)
this is very annoyng because for the final user the impression is that the number of issues has explosed and the system is unstable
I reccomend to increment issue key only when issue creation is succeful.
- causes
-
-
- Closed
-
[JRASERVER-22110] Jira issue creation increments issue key counter even if creation fails (producing big gap in issue numbering)
| Minimum Version | New: 4.01 |
| Workflow | Original: JAC Bug Workflow v2 [ 2845809 ] | New: JAC Bug Workflow v3 [ 2928218 ] |
| Status | Original: Resolved [ 5 ] | New: Closed [ 6 ] |
| Workflow | Original: JIRA Bug Workflow w Kanban v7 - Restricted [ 2585542 ] | New: JAC Bug Workflow v2 [ 2845809 ] |
| Workflow | Original: JIRA Bug Workflow w Kanban v6 - Restricted [ 1526908 ] | New: JIRA Bug Workflow w Kanban v7 - Restricted [ 2585542 ] |
| Labels | New: affects-server |
| Component/s | New: Issue Creation - Issue Create Dialog [ 24490 ] | |
| Component/s | Original: Issue Operations [Deprecated] [ 12761 ] |
| Workflow | Original: JIRA Bug Workflow w Kanban v6 [ 664464 ] | New: JIRA Bug Workflow w Kanban v6 - Restricted [ 1526908 ] |
| Workflow | Original: JIRA Bug Workflow w Kanban v5 [ 647815 ] | New: JIRA Bug Workflow w Kanban v6 [ 664464 ] |
| Workflow | Original: JIRA Bug Workflow w Kanban v5 [ 266502 ] | New: JIRA Bug Workflow w Kanban v6 [ 647815 ] |
RE: The above comment, I'd suggest that Atlassian needs to address this bug AND the so called 'root cause' (which is actually just a related bug, not a cause per se)
Closing with 'Won't Fix' for a known bug is pretty poor really.
This issue has affected us, to the tune of a 13000 increase in the 'pcounter' value. Alarmingly, when we restored the DataBase (for unrelated reasons) last week, therer were 13000 additional/erroneous tickets in the system, related directly to the above issue.
This required manual intervention/deletion, and raised data integrity/reliability concerns for our users.
It's hard for us to pinpoint the exact scenario that led to this, but needless to say it's far from ideal and was directly caused by the 'pcounter' issue outlines above.
It's also frustrating that the issues you have that relate to this issue are generally marked as 'won't fix', for what is an obvious and overt oversight.
If issue creation fails, DO NOT increase the 'pcounter'/write to the database.