CSV Issue imports encounter "Fatal error during import" w/ validator

JC May 8, 2016

We need to import ~500-2000 issues daily from a legacy ticketing system. Many will be duplicates. We created a validator to locate the duplicates (based off their unique summary) and prevent their creation. The import is performed by end-users on our team, using the issue -> 'import from csv' link

We see a "Fatal error during import" everytime we use the validator

2016-05-05 07:51:29,439 INFO - Importer started!
2016-05-05 07:51:29,440 INFO - Engine is running in Import mode
2016-05-05 07:51:29,450 INFO - All issues will be imported to project: TestProject (TEST)
2016-05-05 07:51:29,454 INFO - Creating issue: ExternalIssue
{externalId=autoid-4493924815619197614, summary=CM1, issueType=CM Unknown Subtask}
2016-05-05 07:51:29,693 ERROR - Fatal error during import
java.lang.NullPointerException
at com.atlassian.jira.config.DefaultSubTaskManager.createSubTaskIssueLink(DefaultSubTaskManager.java:582)
at sun.reflect.GeneratedMethodAccessor2522.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.atlassian.plugin.osgi.hostcomponents.impl.DefaultComponentRegistrar$ContextClassLoaderSettingInvocationHandler.invoke(DefaultComponentRegistrar.java:134)
at com.sun.proxy.$Proxy484.createSubTaskIssueLink(Unknown Source)
at sun.reflect.GeneratedMethodAccessor2522.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.doInvoke(ServiceInvoker.java:58)
at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:62)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.osgi.service.util.internal.aop.ServiceTCCLInterceptor.invokeUnprivileged(ServiceTCCLInterceptor.java:56)
at org.springframework.osgi.service.util.internal.aop.ServiceTCCLInterceptor.invoke(ServiceTCCLInterceptor.java:39)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.osgi.service.importer.support.LocalBundleContextAdvice.invoke(LocalBundleContextAdvice.java:59)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy4201.createSubTaskIssueLink(Unknown Source)
at com.atlassian.jira.plugins.importer.imports.importer.impl.CompatibilityUtil.createSubTaskIssueLink(CompatibilityUtil.java:137)
at com.atlassian.jira.plugins.importer.compatibility.CompatibilityBridgeUtils.createSubTaskIssueLink(CompatibilityBridgeUtils.java:172)
at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.createSubTaskLink(BulkCreateDataImporter.java:326)
at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.doImportSubtasks(BulkCreateDataImporter.java:298)
at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.runImporterEngine(BulkCreateDataImporter.java:175)
at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.doImport(BulkCreateDataImporter.java:148)
at com.atlassian.jira.plugins.importer.imports.importer.impl.ImporterCallable.call(ImporterCallable.java:26)
at com.atlassian.jira.plugins.importer.imports.importer.impl.ImporterCallable.call(ImporterCallable.java:15)
at com.atlassian.jira.task.TaskManagerImpl$TaskCallableDecorator.call(TaskManagerImpl.java:528)
at com.atlassian.jira.task.TaskManagerImpl$TaskCallableDecorator.call(TaskManagerImpl.java:491)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at com.atlassian.jira.task.ForkedThreadExecutor$ForkedRunnableDecorator.run(ForkedThreadExecutor.java:254)
at java.lang.Thread.run(Thread.java:745)

It doesn't matter if its a subtask, or a new issue its always resulted in the issue.

The validator looks like this,

the validator is a "Validation based on JQL query"
JQL Query:

project = "Project Name" AND summary ~ "%{00000}"


Condition: number of issues returned by the JQL query satisfies a boolean expression, with "Ephemeral number 1" (code

{00058}) storing the number of returned issues
Boolean expression:

{00058} = 0

 

Anybody have any ideas on how we can use this to prevent duplicates without it error out? Ive tried this as an administrator and it throws the same errors as well. We have attempted to import with a clean CSV file thats two lines long to ensure its not related to bad CSV data - and we always face the same issue. 

Thanks! 

5 answers

4 votes
Michael Partyka
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 8, 2016

Hi,

Since JIRA 6.1 If I am correct you have build in validator.

Try to firstly import only issues without substasks and tell us about the result.

 

crf
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 8, 2016

 

It doesn't matter if its a subtask, or a new issue its always resulted in the issue.

OP claims to have already done this.

JC May 8, 2016

yes, it's been attempted. We have the issue regardless. 100% of the imports are fine without the validator, and 100% fail with the validator. We have tried the admin and user level imports and encounter the same issue. I've also tried a couple different pieces of logic in the Boolean comparison, and queries locating different mapped fields and continue to encounter the fatal error

 

were on Jira 6.4+ right now - do you know of any easy alternatives? We can't map to the issue key for various reasons, or that would have been our go-to

1 vote
crf
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 8, 2016

I think that you should report this as a bug.  For whatever reason, it is attempting to create this issue as a subtask (its issue type suggests that this is the correct thing for it to do), and validation succeeds but the actual creation attempt fails.  It then tries to link the issue as a subtask of the parent issue, but since it wasn't actually created, there is nothing to link and it gets an NPE.

crf
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 8, 2016
private MutableIssue createIssue(final ExternalIssue ei, final IssueService.CreateValidationResult validationResult) {
   final IssueService.IssueResult issueResult = bridgeUtils.create(issueService, authenticationContext.getUser(), validationResult);
   final MutableIssue issue = issueResult.getIssue();
   if (!issueResult.isValid()) {
      printErrors(validationResult);
   } else {
      log.log("Issue created successfully with Key [%s], %s", issue.getKey(), ei);
      stats.incrementCreated();
      importInfo.setLastCreatedIssue(issue);
   }
   return issue;
}

 

If createIssue fails, it logs the errors (the call to printErrors does that), but in the end returns issue anyway, and that would be null.

 

crf
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 8, 2016
if (validationResult.isValid()) {
   String issueKey = null;
   if (isValidationMode) {
      log.log("No problems found with issue '%s'", ei.getSummary());
      stats.incrementCreated();
   } else {
      final MutableIssue subTaskIssue = createIssue(ei, validationResult);
      createSubTaskLink(subTaskIssue, subtaskParentId);
      issueKey = subTaskIssue.getKey();
   }
   saveNecessaryInfo(issueInputParameters, issueKey, ei);
} else {
   printErrors(validationResult);
}

 

So subTaskIssue can be null here, and createSubTaskLink doesn't tolerate a null argument (as well it shouldn't).

 

crf
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 8, 2016

Mysteries I didn't solve:

  • I don't see any way to reach this particular stack trace except when subtasks are involved.  If you are also seeing NPEs when creating ordinary issues, then the stack trace is probably different.
  • I can't think of a good reason for the validator to succeed but the actual issue creation to fail.  That may be a bug in JIRA itself, but the best way to investigate this is probably for you to report the problem with example import data for triggering the issue.
JC May 9, 2016

Sorry for the late response, I'm too new to post more than once or twice in X hours for this site
I reported this as a bug as you have suggested, https://ecosystem.atlassian.net/browse/JIM-1735 hopefully thats correct
 

 

A standard issue being imported would present the following

2016-05-09 06:07:52,534 INFO - Importer started!
2016-05-09 06:07:52,534 INFO - Engine is running in Import mode
2016-05-09 06:07:52,536 INFO - All issues will be imported to project: TestProject (TEST)
2016-05-09 06:07:52,536 INFO - Creating issue: ExternalIssue{externalId=autoid-5517151439465571060, summary=CM1, issueType=11704}
2016-05-09 06:07:52,624 ERROR - Fatal error during import
java.lang.NullPointerException
	at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.doImportIssues(BulkCreateDataImporter.java:236)
	at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.runImporterEngine(BulkCreateDataImporter.java:173)
	at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.doImport(BulkCreateDataImporter.java:148)
	at com.atlassian.jira.plugins.importer.imports.importer.impl.ImporterCallable.call(ImporterCallable.java:26)
	at com.atlassian.jira.plugins.importer.imports.importer.impl.ImporterCallable.call(ImporterCallable.java:15)
	at com.atlassian.jira.task.TaskManagerImpl$TaskCallableDecorator.call(TaskManagerImpl.java:528)
	at com.atlassian.jira.task.TaskManagerImpl$TaskCallableDecorator.call(TaskManagerImpl.java:491)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at com.atlassian.jira.task.ForkedThreadExecutor$ForkedRunnableDecorator.run(ForkedThreadExecutor.java:254)
	at java.lang.Thread.run(Thread.java:745)

Thanks for your responses Chris

crf
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 9, 2016

Ok, I commented on the issue that you opened.  As I say there, although it is a different code path, it has essentially the same behaviour.  In both cases, validation is passing but the issue does not get created successfully anyway, and this results in createIssue returning a null that doesn't get handled gracefully.  It isn't clear to me what the root cause of all of this is, but there is definitely a bug here.  Even if it turns out that something is wrong with your input data, an NPE is obviously not the right way for it to tell you that. wink

Mark Hortman February 28, 2017

I had this happen once and it was because I confused Epic link with Epic name.  I was importing stories that had an epic link, but had mapped to Epic name.   Validated fine, but upon import JIRA gave me the above error.

0 votes
MONIKA DOTASARA April 28, 2017

Hi,

I was also facing the same issue while importing issues because I was not mapping a mandatory field, once I mapped all mandatory field, issue was resolved for me & I was able to import the issues successfully.

Please check if you are providing all the mandatory fields before importing. Not sure but may be this can help. :)

Rajesh Ramankutty February 9, 2019

 

hi @MONIKA DOTASARA did you resolved this issue we also facing the same issue

MONIKA DOTASARA February 26, 2019

Hi @Rajesh Ramankutty ,

Yeah, as i mentioned when i mapped all the required fields, the issue was resolved for me.

Rajesh Ramankutty March 14, 2019

@MONIKA DOTASARA  For me also its working fine but in some project it is not working

i dont know why?

Jose Ramirez May 16, 2019

I'm seeing the same thing on v. 7.5.2 after I run validation and it tells me 'success', I begin the import, and it fails with the following stack trace:



2019-05-16 09:24:11,534 INFO - Importer started!

2019-05-16 09:24:11,535 INFO - Engine is running in Import mode

2019-05-16 09:24:11,546 INFO - All issues will be imported to project: TEST SEOPT (TSEOPT)

2019-05-16 09:24:11,546 INFO - Creating issue: [externalId='autoid-7452376091868916032', summary='ADA_ VISIBLE text indicating card state/status is in English in both Recurring Payments and Cards sections']

2019-05-16 09:24:11,577 ERROR - Fatal error during import

java.lang.NullPointerException

        at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.doImportIssues(BulkCreateDataImporter.java:235)

        at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.runImporterEngine(BulkCreateDataImporter.java:172)

        at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.doImport(BulkCreateDataImporter.java:147)

        at com.atlassian.jira.plugins.importer.imports.importer.impl.ImporterCallable.call(ImporterCallable.java:26)

        at com.atlassian.jira.plugins.importer.imports.importer.impl.ImporterCallable.call(ImporterCallable.java:15)

        at com.atlassian.jira.task.TaskManagerImpl$TaskCallableDecorator.call(TaskManagerImpl.java:458)

        at com.atlassian.jira.task.TaskManagerImpl$TaskCallableDecorator.call(TaskManagerImpl.java:426)

        at java.util.concurrent.FutureTask.run(FutureTask.java:266)

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

        at java.util.concurrent.FutureTask.run(FutureTask.java:266)

        at com.atlassian.jira.task.ForkedThreadExecutor$ForkedRunnableDecorator.run(ForkedThreadExecutor.java:216)

        at java.lang.Thread.run(Thread.java:748)



End.

No detail. This was a 1 issue import, that passed validation before attempting.
John Wokurka August 30, 2019

Has anyone been able to solve this or find a work around?

Jose Ramirez August 30, 2019

Yes, here was my strategy.

Start with 1 issue, and the minimum fields necessary to import.

If that 1 issue works, add another field mapping  and repeat, until you find the offending field.

Leave out the offending field, analyze it later, there maybe other offending fields. I think I had 2 fields that caused this.

I solved this back in May, so my memory may be slightly off but you get the idea.

0 votes
JC May 8, 2016

6.4x+ Mr. Fuller

0 votes
crf
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 8, 2016

What JIRA Version?

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events