Uploaded image for project: 'Jira Software Data Center'
  1. Jira Software Data Center
  2. JSWSERVER-13530

Backlog doesn't show issues in the correct sprints

XMLWordPrintable

      Summary

      The Agile Backlog doesn't show issues in the correct sprints. Moving issues to sprints reverts back after refreshing the page.

      Cause

      The scenario mentioned below is only an example of the scenario where this issue occurs. There could be more causes for this problem. We are working on our side on identifying more causes.

      1. The index is not reindexing changes to the Sprint correctly because there is, or used to be, another field called "Sprint" with a different data type.
        Because the Backlog uses the index, although the issues are correctly modified on the backend, they are displayed incorrectly on the boards.
      2. There are reports that customers on JIRA 7.2 have run into this despite not having another "Sprint" field. Exact cause is still unknown.

      Check if affected:

      This DB query returns issues affected by this:

      select p.pkey ||'-'|| i.issuenum as key, ci.field, ci.newvalue, ci.newstring from changegroup cg join changeitem ci on cg.id = ci.groupid left join jiraissue i on cg.issueid = i.id left join project p on i.project = p.id where ci.field = 'Sprint' and newvalue is NULL;

      For MySQL use:

      select  CONCAT(p.pkey, "-", i.issuenum)AS 'Issue key', ci.field, ci.newvalue, ci.newstring from changegroup cg join changeitem ci on cg.id = ci.groupid left join jiraissue i on cg.issueid = i.id left join project p on i.project = p.id where ci.field = 'Sprint' and newvalue is NULL;

      Environment

      • JIRA Software Cloud and Server

      Steps to Reproduce

      1. Create a Custom Field type "labels" and name it "Sprint"
      2. On a certain issue add a label and remove a label
      3. On the backlog view, move that issue to a different sprint

       There are reports that customers on JIRA 7.2 have run into this despite not having another "Sprint" field. Exact cause is still unknown.

      Expected Results

      Issue is correctly moved between sprints and changes persist.

      Actual Results

      The issue is dragged over to the sprint.
      The below exception is thrown in the JIRA log: Error indexing issue

      2016-04-11 10:52:07.559050500 2016-04-11 10:52:07,548 http-nio-3000-exec-10 WARN sysadmin 652x1263x1 9aomkb 103.233.242.8 /rest/greenhopper/1.0/sprint/rank [c.a.j.issue.index.DefaultIssueDocumentFactory] Error indexing issue BDBPP-145: Dropping 'customfield_10402'
2016-04-11 10:52:07.559053500 java.lang.NullPointerException
2016-04-11 10:52:07.559054500 	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.movedToSprintAfterStartDate(SprintHistoryEntryFactory.java:217)
2016-04-11 10:52:07.559055500 	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.lambda$null$6(SprintHistoryEntryFactory.java:188)
2016-04-11 10:52:07.559093500 	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory$$Lambda$633/11364990.apply(Unknown Source)
2016-04-11 10:52:07.559095500 	at java.util.Optional.map(Optional.java:215)
2016-04-11 10:52:07.559095500 	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.lambda$removeOtherNonActiveSprints$7(SprintHistoryEntryFactory.java:188)
2016-04-11 10:52:07.559102500 	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory$$Lambda$631/2285389.test(Unknown Source)
2016-04-11 10:52:07.559103500 	at java.util.Collection.removeIf(Collection.java:414)
2016-04-11 10:52:07.559104500 	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.removeOtherNonActiveSprints(SprintHistoryEntryFactory.java:185)
2016-04-11 10:52:07.559111500 	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.getSprintChangeHistoryForIssue(SprintHistoryEntryFactory.java:154)
2016-04-11 10:52:07.559112500 	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.getSprintChangeHistory(SprintHistoryEntryFactory.java:52)
2016-04-11 10:52:07.559114500 	at com.atlassian.greenhopper.customfield.sprint.SprintCustomFieldIndexer.addDocumentFields(SprintCustomFieldIndexer.java:45)
2016-04-11 10:52:07.559118500 	at com.atlassian.greenhopper.customfield.sprint.SprintCustomFieldIndexer.addDocumentFieldsSearchable(SprintCustomFieldIndexer.java:30)
2016-04-11 10:52:07.559120500 	at com.atlassian.jira.issue.index.indexers.impl.AbstractCustomFieldIndexer.addIndex(AbstractCustomFieldIndexer.java:40)
2016-04-11 10:52:07.559121500 	at com.atlassian.jira.issue.index.DefaultIssueDocumentFactory$Builder.add(DefaultIssueDocumentFactory.java:84)
2016-04-11 10:52:07.559126500 	at com.atlassian.jira.issue.index.DefaultIssueDocumentFactory$Builder.addAll(DefaultIssueDocumentFactory.java:75)
2016-04-11 10:52:07.559127500 	at com.atlassian.jira.issue.index.DefaultIssueDocumentFactory.apply(DefaultIssueDocumentFactory.java:50)
2016-04-11 10:52:07.559133500 	at com.atlassian.jira.issue.index.DefaultIssueDocumentFactory.apply(DefaultIssueDocumentFactory.java:30)
2016-04-11 10:52:07.559134500 	at com.atlassian.jira.issue.index.DefaultIssueIndexer$DefaultDocumentCreationStrategy.get(DefaultIssueIndexer.java:553)
2016-04-11 10:52:07.559135500 	at com.atlassian.jira.issue.index.DefaultIssueIndexer.lambda$reindexIssues$1(DefaultIssueIndexer.java:166)
2016-04-11 10:52:07.559140500 	at com.atlassian.jira.issue.index.DefaultIssueIndexer$$Lambda$593/22309686.perform(Unknown Source)
2016-04-11 10:52:07.559141500 	at com.atlassian.jira.issue.index.DefaultIssueIndexer.lambda$null$2(DefaultIssueIndexer.java:305)
2016-04-11 10:52:07.559142500 	at com.atlassian.jira.issue.index.DefaultIssueIndexer$$Lambda$600/4056176.get(Unknown Source)
2016-04-11 10:52:07.559143500 	at com.atlassian.jira.index.SimpleIndexingStrategy.get(SimpleIndexingStrategy.java:7)
2016-04-11 10:52:07.559147500 	at com.atlassian.jira.index.SimpleIndexingStrategy.get(SimpleIndexingStrategy.java:5)
2016-04-11 10:52:07.559148500 	at com.atlassian.jira.issue.index.DefaultIssueIndexer.lambda$perform$3(DefaultIssueIndexer.java:303)
2016-04-11 10:52:07.559150500 	at com.atlassian.jira.issue.index.DefaultIssueIndexer$$Lambda$594/28919328.consume(Unknown Source)
2016-04-11 10:52:07.559156500 	at com.atlassian.jira.util.collect.CollectionUtil.foreach(CollectionUtil.java:39)
2016-04-11 10:52:07.559157500 	at com.atlassian.jira.util.collect.CollectionUtil.foreach(CollectionUtil.java:52)
2016-04-11 10:52:07.559158500 	at com.atlassian.jira.issue.util.IssueObjectIssuesIterable.foreach(IssueObjectIssuesIterable.java:24)
2016-04-11 10:52:07.559159500 	at com.atlassian.jira.issue.index.DefaultIssueIndexer.perform(DefaultIssueIndexer.java:282)
2016-04-11 10:52:07.559163500 	at com.atlassian.jira.issue.index.DefaultIssueIndexer.reindexIssues(DefaultIssueIndexer.java:162)
2016-04-11 10:52:07.559165500 	at com.atlassian.jira.issue.index.DefaultIndexManager.reIndexIssues(DefaultIndexManager.java:541)
2016-04-11 10:52:07.559166500 	at com.atlassian.jira.issue.index.DefaultIndexManager.reIndexIssues(DefaultIndexManager.java:517)
2016-04-11 10:52:07.559167500 	at com.atlassian.jira.issue.index.DefaultIndexManager.reIndexIssues(DefaultIndexManager.java:500)
2016-04-11 10:52:07.559174500 	at com.atlassian.jira.issue.index.DefaultIndexManager.release(DefaultIndexManager.java:489)
2016-04-11 10:52:07.559175500 	... 3 filtered
2016-04-11 10:52:07.559176500 	at java.lang.reflect.Method.invoke(Method.java:497)
2016-04-11 10:52:07.559176500 	at com.atlassian.jira.config.component.SwitchingInvocationHandler.invoke(SwitchingInvocationHandler.java:22)
2016-04-11 10:52:07.559182500 	at com.sun.proxy.$Proxy11.release(Unknown Source)
2016-04-11 10:52:07.559183500 	... 3 filtered

      A refresh of the backlog shows the issue back on the previous location.

      Notes

      The problem is related to historic events. It will only affect issues that have the duplicate "Sprint" field cleared in the past. New issues where labels weren't modified, won't have the problem.

      Workaround

      Please be aware that unfortunately the workaround here is temporary and the issue comes back after some time

      Always generate backup of your database before making any changes to it via SQL. Any workaround requiring SQL changes carries inherent risk so a backup of your DB is essential to restore working conditions if there is a critical problem. This workaround should be tested in a clone of your Production environment prior to attempting it in Production.

      1. Backup all the "sprint-removal history items" into a separate table, and remove them from the initial table 
        create table changeitem_quarantine_jira721 as
select ci.* from changeitem ci
where ci.field = 'Sprint'
and   ci.newvalue is null;
      2. Remove them from the initial changeitem table: 
        DELETE from changeitem ci where ci.id in (select id from changeitem_quarantine_jira721);
      3. Restart JIRA
      4. Full/Locked reindexing

      If any misbehaviour happens, the records can be restored again with the statement:

      insert into changeitem
select * from changeitem_quarantine_jira721 where id not in (select id from changeitem);

              apawelczyk Artur Pawelczyk (Inactive)
              mfernandezbadii Mauro Badii (Inactive)
              Votes:
              96 Vote for this issue
              Watchers:
              158 Start watching this issue

                Created:
                Updated:
                Resolved: