Cache Delegation: null keys are not permitted
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Problem
After updating custom fields/screens in a project, the project settings become inaccesible, also issues in project (and possibly other projects) cannot be loaded.
The users might see an error message like Error rendering 'com.atlassian.jira.jira-view-issue-plugin:details-module'
The following appears in the atlassian-jira.log:
2018-06-01 15:28:49,010 http-nio-8080-exec-20 url:/rest/projectconfig/lates...8/48/fields ERROR AC32893 928x435093x2 jbf3oj 10.63.2.195,10.152.4.156 /rest/projectconfig/latest/issuetype/COE18/48/fields [c.a.p.r.c.error.jersey.ThrowableExceptionMapper] Uncaught exception thrown by REST service: java.lang.NullPointerException: null keys are not permitted
com.atlassian.cache.CacheException: java.lang.NullPointerException: null keys are not permitted
at com.atlassian.cache.ehcache.DelegatingCache.get(DelegatingCache.java:108)
at com.atlassian.jira.cache.DeferredReplicationCache.get(DeferredReplicationCache.java:48)
at com.atlassian.jira.issue.fields.screen.DefaultFieldScreenSchemeManager.getFieldScreenScheme(DefaultFieldScreenSchemeManager.java:69)
at com.atlassian.jira.issue.fields.screen.issuetype.IssueTypeScreenSchemeEntityImpl.getFieldScreenScheme(IssueTypeScreenSchemeEntityImpl.java:81)
at com.atlassian.jira.issue.fields.screen.issuetype.IssueTypeScreenSchemeImpl.getEffectiveFieldScreenScheme(IssueTypeScreenSchemeImpl.java:120)
at com.atlassian.jira.projectconfig.issuetypes.fields.DefaultIssueTypeConfigFieldsHelper.getFieldScreen(DefaultIssueTypeConfigFieldsHelper.java:73)
at com.atlassian.jira.projectconfig.issuetypes.fields.DefaultIssueTypeConfigFieldsHelper.lambda$getIssueTypesSharingScreen$0(DefaultIssueTypeConfigFieldsHelper.java:87)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at com.atlassian.jira.projectconfig.issuetypes.fields.DefaultIssueTypeConfigFieldsHelper.getIssueTypesSharingScreen(DefaultIssueTypeConfigFieldsHelper.java:90)Diagnosis
Diagnostic Steps
- referenced fieldscreenscheme in issuetypescreenschemeentity is null or is not in existing fieldscreenscheme
- Steps like these will often involve checking data using SQL
SELECTqueries to see if the application is in a particular state OR any checks to ensure that the customers environment is in a state that will bring about the described problem
Cause
It is unknown how this data becomes invalidly referenced.
Resolution
The following queries will identify rows in this state:
select * from issuetypescreenschemeentity where fieldscreenscheme is null; select * from issuetypescreenschemeentity where fieldscreenscheme not in (select id from fieldscreenscheme);Expectation is that no results are returned, as all entries should have a value in here. If something is returned, then it's a bad reference.Before performing DELETEoperations please see:Always back up your data before performing any modifications to the database. If possible, test any alter, insert, update, or delete SQL commands on a staging server first.
- The rows identified above should be deleted by primary key identifier.
- If nothing is returned from the previous query, just create a new screen scheme and associate it with the project.