I am facing this in Jira version 8.5.8.

Atlassian Ticket raised - GHS-217202

We are using v8.4.1#804002 and is also experiencing this issue.

We are using v8.5.3#805003-sha1:b4933e0 and are still seeing this issue. Is there anything that can be done.

we are using v8.2.3#802003 and the issue is still present. 

anyhing we can do?

does it depend on the index structure? sometimes re-indexing helps for some days.

We solved the problem with a database query on the changeitem table.

We found some data which had the content  'null'

We changed the content to an empty string like: ""

You should have a testsystem, a database admin and of course: a full backup of your JIRA installation!!

Hello, I thought we were beyond the problem, we had it with 724 and it was gone after upgrading  to 727 BUT its suddenly happening again on 727.

Hello Peter, after upgrade to 7.2.7 we haven't faces this error any more, from our perspective it is fixed in 7.2.7  

Hello Peter, as far as I know issue was fixed in 7.3.0 version, though did not test it yet.

Thank you to everyone who share knowledge on the page.

We ran in this issue too: Having a JIRA 6.3.12, perfom an update on a testsystem to 7.2.3 and running into the indexing Problem too: Error indexing issue xxxxx-123: Dropping 'customfield_10007' (the sprint customfield). The SQL Query shows a lot of Issues when we excuted it.

Today I tried another update on the test system: I installed a 7.2.7 and imported my 6.3.12 data.
As I understand the conversation on this page, the error should be fixed in 7.2.7

I still get errors. Was anyone successful and can confirm that 7.2.7 fixes the error?

cpascoe, the problem affects Data Center instances.

By "server" we mean both traditional single-node instances and Data Center. If an issue affects only specific type of instance, we will say it explicitly.

Does this also affect Data Center instances or only server?

A small note:
We have upgraded from JIRA 7.2.1 to 7.2.7 and reinstated the quarantined history-data (the data which was deleted with the workaround):

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

Result: The bug is gone and reinstating the data has also corrected the Sprint-Burndown Charts again (If you removed an issue from a running sprint, the workaround caused the workload of the issue to stay in the sprint-burndown estimation sum).

Tesr

Hi rsomma,

No, it's not safe. Fix has been shipped with the version JIRA 7.2.7 and 7.3.0 only. I'll add the 7.2.6 to affected versions to prevent further confusion.

–
Cheers,
Ignat
JIRA Bugmaster.

I don't see 7.2.6 listed under 'affects versions" - is it safe to say that version is not impacted?

Hi Christian Madrigal,

I've provided the information about which release and estimated timeframe few comments above.

Cheers,
Ignat.

Is there a target date for the release? Looks like this issue was discovered on April. 

Yes.  We also tried to edit affected issues, but it don't help.  we are temporarily cloning affected issues for a quick and less intrusive workaround.

Any chance of a hotfix for this issue?  we only just upgrades to version 7, and not super keen to have to upgrade again so soon.

I tried the bulk change that Jonas mentioned and it did not work for me... 

Hi Jonas,

many thanks for informing us about this potential workaround. As we've several hundred affected issues, I tried it in our installation (bulk-add of labels), but unfortunately w/o any success. So we still need to wait for the patch in 7.2.7 release. This for all others as information.

Cheers
Kai

My product managers found a viable workaround by selecting all affected issues and doing a trivial bulk change of something unimportant (i.e. "touching" the issues) and then they were all back in the sprint. In case that could help anyone else while we wait for the fix.

We see this exact issue when an issue has been added then removed from a sprint, or when a sprint is renamed. We ended up having to clone the affected issues as a workaround in the mean time while we can figure out an automated way to look for this problem... If you need any logs/evidence etc reach out to us. 

Hi Ben, 

We usually aim at shipping bugfix releases at bi-weekly cycle, sometimes, if another critical issue is identified, we may consider postponing the release. We can postpone it if we will have quality concerns too, e.g. when issue is identified internally when we are using the release build candidate.

We also are not likely ship the release in next 2 weeks due to holiday season.
We will be aiming to ship it shortly after. Given said that we can not commit to the release date on 7.2.7 to that extend that you can plan your release schedule.

–
Cheers,
Ignat.

+1
Our engineers reverted to using post it notes.

Do you have an estimated release date for 7.2.7?  

Hi everyone,

We are planning to ship 7.2.7 soon, which will resolve the issue, as of status - issue is still in progress.

Cheers,
Ignat
JIRA Bugmaster.

This issue was not included in 7.2.6 release?

It's great that issue has changed state to In-Progress. Is an estimation when we can see it in the official release?

Hi, we deal with the sam issue. It would be nice to have it fixed.

There is a different workaround. Create a clone of the issue and then you can drag and drop it into the sprint. But it is not convinient when you have more issues .

Yes, here at Avaloq we have the same problem. We have recently upgraded to JIRA 7.2.5 (JIRA Software 7.2.4) and now we face the same issue as described by yossiz in the previous comment.

Atlassian please think of a workaround. Is there no way to move issues to a sprint in a different/alternative way?

If it helps, this happens to us on some issues since we upgraded JIRA+Agile 6.4 to JIRA Software 7.2

The issue's sprint field shows the sprint, but in the board it appears in the backlog, and any attempt to move it to a sprint, or just re-index,  shows the following in the log:

2016-11-27 08:27:35,502 JiraTaskExectionThread-1 WARN administrator 505x5681x1 16jss81 xx.xx.xx.xx /secure/admin/jira/IndexReIndex.jspa [c.a.j.issue.index.DefaultIssueDocumentFactory] Error indexing issue XXXXX-73166: Dropping 'customfield_10231'
2016-11-27 08:27:35,533 JiraTaskExectionThread-1 WARN administrator 505x5681x1 16jss81 xx.xx.xx.xx /secure/admin/jira/IndexReIndex.jspa [c.a.j.issue.index.DefaultIssueDocumentFactory] Error indexing issue XXXXX-73166: Dropped: [customfield_10231]

customfield_10231 refers to the Sprint field.

We don't have, and didn't have, another custom field named Sprint

problem is, issue appear again later.

It is mission critical for us.  We can't have issues disappearing from kanban boards.  This is the second time we've had to have an outage to apply the temporary workaround.

Can we please get an update on the fix for this?

We followed the instruction and were able to fix more than 2k issues. Thank you!

This is also affecting our users.

Project Managers are NOT happy.

Hope this gets fixed soon.

We are also affected by this bug.  Upon further investigation, it appears that the affected issues (identified by the sql query above) have one thing in common from the Activity tab.  I see in each one the activity:

<user> removed the Sprint of <JIRA reference>

Hopefully this helps you with a permanent fix.  I have had to organize a second outage now to apply the work around for this issue.

Hi Kai, hi everyone!

We acknowledge the importance of this issue and it's in our list of bugs to address asap.
Please follow the issue for the updates.

Cheers,
Ignat
JIRA Bugmaster.

I think most about how important and urgent this bug is, has already been written above. Nevertheless I'd like to point out that we have hundred of projects and agile boards in our installation. We receive requests on a daily base that issues cannot be assigned to sprints. All we can do currently, is .... waiting for the fix, as the temporary workaround would cost us roughly two hours including a scheduled downtime potentially each day, which is simply not suitable.

I am not bashing in any way, as I am still a huge supporter and fan of JIRA, but I'd like to let anyone in control set focus on this issue.

Cheers

Kai

Could you give us more detail than "short term" ? Obviously updates to the the Jira application in 7.2.x have caused many issues, and while this would be forgivable normally, since we are FORCED to upgrade to the latest version to be able to roll a project off of Cloud, you're basically now forcing people into a broken state.

Right now our entire company is messed up because we migrated a project from Cloud to Internal and the software stopped working correctly. I attempted to roll back from 7.2.3 to 7.1.9 ( our last known working version ) but the back port failed so we're stuck.

Greg Booth

Hi queenie.chow,

This is a priority issue for us already, and we plan to address this in the short-term timeframe.

–
Cheers,
Ignat
JIRA Bugmaster.

We are having the same Problem after upgrading from Jira 7.1.4 to Jira 7.2.2 with the Dropping 'customfield_10005' and 'NullPointerException
at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.movedToSprintAfterStartDate" error. 

Have a question to atlassian: are you planing to rise the priority of this bug?

I rechecked my steps to reproduce, when I was testing it Sprint A was already started. I will edit the comments to reflect exactly what I did to reproduce it every time. (There are other variations of the steps that also reproduce it, but the edited version is what I was able to reproduce multiple times this morning). I will have to determine if we are able for security reasons to send the xml backup - we already have an open Support issue referencing this.

The specific stack trace we are seeing is on the line than the one listed in the description NullPointerException
at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.movedToSprintAfterStartDate(SprintHistoryEntryFactory.java:217)

Hi ljfields1459763351 I tried the steps mentioned by you in this comment but unfortunately I was not able to reproduce the problem.

Could you please create a Support issue with us and attach your xml backup to the case so that we can look closer at the data on the instance?

That would help us determining the root cause of the problem here.

There are much easier steps to reproduce that cause the breakage every time, and would likely be a common use case:

1. Create Sprint A and Sprint B so that they are both visible on the same board.
2. Start Sprint A but do NOT Start Sprint B
3. Create a new issue, adding it to Sprint A during creation.
4. Go to the work view, right click on the issue and select "Remove from Sprint" - Note that the dialog states that it has been added to Sprint B (the next open sprint)

Reload the planning view, and note that the issue appears in the backlog, not Sprint B
Look at the details of the issue. Note that the Sprint field is populated with Sprint B (despite it not showing up on that Sprint).
At this point the issue is completely broken, will not be indexed, and will not stick to any sprint.

I executed Leonard's step by step instruction. My result ist: Same behaviour here.
That is really terrible and needs to become either a higher priority or better a new bug ticket with the label "warranty".

New steps to reproduce:

• Create two new sprints: Sprint A, Sprint B
• Add Stories to Sprint A and start Sprint A
• Create issue "TEST" (referred as TST-1)
• Move issue TST-1 to Sprint B
• Move issue TST-1 to the top of the backlog (removing from Sprint B)
• Move issue TST-1 to the running Sprint A and confirm
• Move issue TST-1 to the top of the Backlog and confirm (removing from Sprint A)

Result: The Sprint field of issue TST-1 cannot be indexed anymore and TST-1 will never show up in a sprint anymore until the workaround SQL is run again.

I totally agree with Leonard! We never had a custom field called "Sprint" in our instance. This behaviour suddenly came after the upgrade to JIRA software 7.2.3.

I agree to either raise the priority of this bug or create a seperate new high-prio bug.

Originally the bug was created due to some exoic issue of someone having created an individual custom field that was named "Sprint".
Most of the followers here however are experiencing a different cause, which is the upgrade from 7.1.x to 7.2.x in combination with a data constallation (without ever having created a Custom field called "Sprint").

So either create two bugs, or rename the cause of this bug from "Having created a custom Sprint field in the past" to "Upgrade from 7.1 to 7.2" and add a new "steps to reproduce" description.
These two bugs are combined as one only because they are similar and can be identified with the same SQL.

The cause and with it the severity however is hugely different.

Hei, same issue happend that Scurm boards can not show some issues in backlog in correct sprint....Redex also throw error on the sprint field. Lots of complaint and pressure from our Jira users. Please fix it soon!!

The same issue here! It makes the Scrum boards useles! Please make change the priority to critical and fix this bug asap! Version 7.2.3

We started having this problem immediately after upgrading from 7.1 to 7.2.1. We have never had a custom field that we added with the name Sprint, it has been a largely Vanilla installation of Jira. This is dramatically impacting our ability to run and manage sprints - when we run the query in the issue description, it returns over 2700 affected issues. The wide scale occurance is is very clearly a bug introduced in 7.2, and needs to be addressed by Atlassian.

The workaround has a big flaw. It seems that sprint reports rely on issues history, and they can be broken after applying the workaround. I can see many tasks in "Issues not completed" section although I removed them from a sprint before starting it.

make sure the commit has to be done after db changes for oracle database users.

answer to: Do you really have to delete this records from the changeitem table again and again?
In other words do you really have to execute the SQL statement again and again?:

Yes we need to execute it again and again, after fix everything fain for couple of days, but after these days users start to complain about same situation- they can not move issues to active sprint

I did the workaround, too. After some days, the SQL query brings new records. And so I have more than one "changeitem_quarantine..." table. But that could be OK because if you remove an issue from a sprint New Value becomes "NULL" and so it fulfills the SQL where condition.
The question is: Do you really have to delete this records from the changeitem table again and again?
In other words do you really have to execute the SQL statement again and again?
I tried to put one of these issues again to a sprint and it went to the sprint and left backlog.
OK I did it with one issue only, but do you have issues which stay in backlog after you did the workaround?
Or are you worried about the SQL query brings new records up?

Same here, as well. 7.2.2, no custom field "sprint".
I actually don't see why this is a "Medium" and why this hasn't been fixed in six months now.

With this not being fixed, you have a sprint board that raises the impression of not being reliable. And the sprint board is one of the main features of JIRA we use in our company. You know the game. Sooner or later users tend to think of the software as being "crappy." I don't know about you guys, but I certainly don't want that. Once you got there, it's a long and hard way back.

Pls raise the severity and fix this.

Have a question to atlassian: are you planing to rise the priority of this bug?

this issue did not allow Jira admin to sleep each second night, now we implemented automatic workaround execution, but db with already 9 tables: table_name="CHANGEITEM_QUARANTINE_`date +"%d-%m-%y"`" doesn't look very nice.

The same in 7.2.2. We have no custom field called "Sprint", only customfield_10005.
I just applied the workaround. It works, but it took only a few minutes to make one of the tasks corrupt. I just removed it from a not started sprint and then tried to add it to this sprint.
In version 7.2.2 the log has a little different line numbers than in 7.2.0:

2016-10-14 22:12:38,785 http-nio-8581-exec-2 WARN lukaszm 1332x53451x1 1nownjc 10.77.34.13,0:0:0:0:0:0:0:1 /rest/greenhopper/1.0/sprint/rank [c.a.j.issue.index.DefaultIssueDocumentFactory] Error indexing issue CSP-186: Dropping 'customfield_10005'
java.lang.NullPointerException
	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.movedToSprintAfterStartDate(SprintHistoryEntryFactory.java:223)
	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.lambda$null$22(SprintHistoryEntryFactory.java:188)
	at java.util.Optional.map(Optional.java:215)
	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.lambda$removeOtherNonActiveSprints$23(SprintHistoryEntryFactory.java:188)
	at java.util.Collection.removeIf(Collection.java:414)
	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.removeOtherNonActiveSprints(SprintHistoryEntryFactory.java:185)
	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.getSprintChangeHistoryForIssue(SprintHistoryEntryFactory.java:154)
	at com.atlassian.greenhopper.customfield.sprint.SprintHistoryEntryFactory.getSprintChangeHistory(SprintHistoryEntryFactory.java:52)
	at com.atlassian.greenhopper.customfield.sprint.SprintCustomFieldIndexer.addDocumentFields(SprintCustomFieldIndexer.java:45)
	at com.atlassian.greenhopper.customfield.sprint.SprintCustomFieldIndexer.addDocumentFieldsSearchable(SprintCustomFieldIndexer.java:30)
	at com.atlassian.jira.issue.index.indexers.impl.AbstractCustomFieldIndexer.addIndex(AbstractCustomFieldIndexer.java:40)
	at com.atlassian.jira.issue.index.DefaultIssueDocumentFactory$Builder.add(DefaultIssueDocumentFactory.java:84)
	at com.atlassian.jira.issue.index.DefaultIssueDocumentFactory$Builder.addAll(DefaultIssueDocumentFactory.java:75)
	at com.atlassian.jira.issue.index.DefaultIssueDocumentFactory.apply(DefaultIssueDocumentFactory.java:50)
	at com.atlassian.jira.issue.index.DefaultIssueDocumentFactory.apply(DefaultIssueDocumentFactory.java:30)
	at com.atlassian.jira.issue.index.DefaultIssueIndexer$DefaultDocumentCreationStrategy.get(DefaultIssueIndexer.java:556)
	at com.atlassian.jira.issue.index.DefaultIssueIndexer.lambda$reindexIssues$1(DefaultIssueIndexer.java:166)
	at com.atlassian.jira.issue.index.DefaultIssueIndexer.lambda$null$2(DefaultIssueIndexer.java:308)
	at com.atlassian.jira.index.SimpleIndexingStrategy.get(SimpleIndexingStrategy.java:7)
	at com.atlassian.jira.index.SimpleIndexingStrategy.get(SimpleIndexingStrategy.java:5)
	at com.atlassian.jira.issue.index.DefaultIssueIndexer.lambda$perform$3(DefaultIssueIndexer.java:306)
	at com.atlassian.jira.util.collect.CollectionUtil.foreach(CollectionUtil.java:39)
	at com.atlassian.jira.util.collect.CollectionUtil.foreach(CollectionUtil.java:52)
	at com.atlassian.jira.issue.util.IssueObjectIssuesIterable.foreach(IssueObjectIssuesIterable.java:24)
	at com.atlassian.jira.issue.index.DefaultIssueIndexer.perform(DefaultIssueIndexer.java:282)
	at com.atlassian.jira.issue.index.DefaultIssueIndexer.reindexIssues(DefaultIssueIndexer.java:162)
	at com.atlassian.jira.issue.index.DefaultIndexManager.reIndexIssues(DefaultIndexManager.java:541)
	at com.atlassian.jira.issue.index.DefaultIndexManager.reIndexIssues(DefaultIndexManager.java:517)
	at com.atlassian.jira.issue.index.DefaultIndexManager.reIndexIssues(DefaultIndexManager.java:500)
	at com.atlassian.jira.issue.index.DefaultIndexManager.release(DefaultIndexManager.java:489)
	... 2 filtered
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.atlassian.jira.config.component.SwitchingInvocationHandler.invoke(SwitchingInvocationHandler.java:22)
	at com.sun.proxy.$Proxy16.release(Unknown Source)
	... 2 filtered
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.atlassian.plugin.util.ContextClassLoaderSettingInvocationHandler.invoke(ContextClassLoaderSettingInvocationHandler.java:26)
	at com.sun.proxy.$Proxy16.release(Unknown Source)
	... 2 filtered
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.atlassian.plugin.osgi.bridge.external.HostComponentFactoryBean$DynamicServiceInvocationHandler.invoke(HostComponentFactoryBean.java:136)
	at com.sun.proxy.$Proxy16.release(Unknown Source)
	at com.atlassian.greenhopper.service.sprint.SprintIssueServiceImpl.updateIssuesInSprint(SprintIssueServiceImpl.java:356)
	at com.atlassian.greenhopper.service.sprint.SprintIssueServiceImpl.updateIssuesInSprint(SprintIssueServiceImpl.java:322)
	at com.atlassian.greenhopper.service.sprint.SprintIssueServiceImpl.moveIssuesToSprint(SprintIssueServiceImpl.java:124)
	at com.atlassian.greenhopper.web.rapid.sprint.SprintRankResource$1.call(SprintRankResource.java:115)
	at com.atlassian.greenhopper.web.rapid.sprint.SprintRankResource$1.call(SprintRankResource.java:88)
	at com.atlassian.greenhopper.web.util.RestCall.response(RestCall.java:42)
	at com.atlassian.greenhopper.web.AbstractResource.createResponse(AbstractResource.java:111)
	at com.atlassian.greenhopper.web.AbstractResource.response(AbstractResource.java:91)
	at com.atlassian.greenhopper.web.rapid.sprint.SprintRankResource.updateSprintAndRank(SprintRankResource.java:87)
	... 2 filtered
	at java.lang.reflect.Method.invoke(Method.java:498)
	... 18 filtered
	at com.atlassian.plugins.rest.module.RestDelegatingServletFilter$JerseyOsgiServletContainer.doFilter(RestDelegatingServletFilter.java:154)
	... 1 filtered
	at com.atlassian.plugins.rest.module.RestDelegatingServletFilter.doFilter(RestDelegatingServletFilter.java:68)
	... 36 filtered
	at com.atlassian.web.servlet.plugin.request.RedirectInterceptingFilter.doFilter(RedirectInterceptingFilter.java:21)
	... 53 filtered
	at com.atlassian.jira.security.JiraSecurityFilter.lambda$doFilter$0(JiraSecurityFilter.java:76)
	... 1 filtered
	at com.atlassian.jira.security.JiraSecurityFilter.doFilter(JiraSecurityFilter.java:74)
	... 16 filtered
	at com.atlassian.plugins.rest.module.servlet.RestSeraphFilter.doFilter(RestSeraphFilter.java:37)
	... 20 filtered
	at com.atlassian.jira.servermetrics.CorrelationIdPopulatorFilter.doFilter(CorrelationIdPopulatorFilter.java:30)
	... 10 filtered
	at com.atlassian.web.servlet.plugin.request.RedirectInterceptingFilter.doFilter(RedirectInterceptingFilter.java:21)
	... 4 filtered
	at com.atlassian.web.servlet.plugin.LocationCleanerFilter.doFilter(LocationCleanerFilter.java:36)
	... 29 filtered
	at com.atlassian.jira.servermetrics.MetricsCollectorFilter.doFilter(MetricsCollectorFilter.java:25)
	... 27 filtered
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:745)
2016-10-14 22:12:38,816 http-nio-8581-exec-2 WARN lukaszm 1332x53451x1 1nownjc 10.77.34.13,0:0:0:0:0:0:0:1 /rest/greenhopper/1.0/sprint/rank [c.a.j.issue.index.DefaultIssueDocumentFactory] Error indexing issue CSP-186: Dropped: [customfield_10005]

we have 1700+ users, 200+ projects, so the issue come back after couple of days,

@Patrick van der Rijst [Avisi] We have noticed after 6 days, but it could happen sooner i guess