The Jira logs are throwing the error "should have a version by now" while performing a bulk edit operation

Summary

The Jira logs are throwing the error "should have a version by now" while performing a bulk edit operation to move multiple issues, and the bulk operation fails:

Note that:

• this error might occur as well while performing a Bulk Cloning operation coming from the 3rd party add-on Bulk Clone Professional for Jira (and the bulk operation will fail):

  1 2 3 4 5 6 7 8 9 2022-02-15 11:36:48,701+0800 JiraTaskExecutionThread-7 ERROR someuser 696x515642x2 u9v3lz /secure/views/bulkedit/BulkCloneOperationDetails!perform.jspa [c.l.j.p.bulkclonepro.operation.BulkCloneOperation] Bulk Clone Pro encountered an error while cloning: com.atlassian.jira.exception.CreateException: ISSUE with id=7564023 should have a version by now at com.atlassian.jira.issue.managers.DefaultIssueManager.createIssue(DefaultIssueManager.java:586) at com.atlassian.jira.issue.managers.DefaultIssueManager.createIssueObject(DefaultIssueManager.java:592) at com.atlassian.jira.issue.managers.RequestCachingIssueManager.createIssueObject(RequestCachingIssueManager.java:188) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source)

• the same error related to Jira comments might also be thrown in the Jira logs, even though they are harmless and don't have any impact on Jira's commenting functionality:

  1 2 3 4 5 6 2022-02-15 11:53:47,748+0800 http-nio-8081-exec-50 url: /secure/CommentAssignIssue.jspa; user: someuser ERROR someuser 713x547883x1 ylhoru /secure/CommentAssignIssue.jspa [c.a.j.e.listeners.search.IssueIndexListener] Error re-indexing comment '19614255' java.lang.IllegalStateException: COMMENT with id=19614255 should have a version by now at com.google.common.base.Preconditions.checkState(Preconditions.java:823) at com.atlassian.jira.issue.index.DefaultIssueIndexer$EntityOperation.lambda$null$0(DefaultIssueIndexer.java:815) at java.base/java.util.Optional.orElseGet(Unknown Source) at com.atlassian.jira.issue.index.DefaultIssueIndexer$EntityOperation.lambda$reload$1(DefaultIssueIndexer.java:814)

Environment

Observed on Jira Server/Data Center 8.13.0 and above.

Diagnosis

• The Jira application is connected to a MySQL database, following the instructions from Connecting Jira applications to MySQL 5.7

• The MySQL database is configured with the default isolation level RR (REPEATABLE-READ)

• There is a proxy database located between the Jira application and the MySQL database, and when removing this layer between the Jira application and the MySQL Database, the errors no longer happen in Jira

• Running either of the following SQL queries is returning some rows:

  • Query 1

    • This query indicates that some issues were added to the jiraissue table in the Jira database without a matching row added to the table issue_version (from Jira 8.13.0 and above, any newly created Jira issue should have a version added to the issue_version table, to ensure proper indexing process)

      1 2 select i.id, p.pkey, i.issuenum from jiraissue i inner join project p on i.project = p.id where i.id not in (select issue_id from issue_version);

  • Query 2

    • This query indicates that some issue comments were added to the jiraaction table in the Jira database without a matching row added to the table comment_version (from Jira 8.13.0 and above, any comments added to Jira issue should have a version added to the comment_version table, to ensure proper indexing process)

      1 2 select * from jiraaction WHERE actiontype = 'comment' AND id not in (select comment_id from comment_version);

Cause

The Jira application uses the isolation level RC (READ-COMMITTED) whenever it sends an SQL query to the MySQL database.

It does not matter what the isolation level is set to at the MySQL server level (for example REPEATABLE-READ). Since the isolation level of each transaction is set to READ-COMMITTED by the Jira application, when the transaction is received by the Database, this transaction will use READ-COMMITTED even if the Database is using a different isolation level.

Atlassian does not mention configuring a specific isolation level at the database level in the documentation Connecting Jira applications to MySQL 5.7 because no configuration needs to be done at the Database level. Even if the isolation level is set to something different at the database level, this isolation level will be overwritten by the level provided by the transaction sent from Jira.

The problem is that, in case a Database proxy is configured between the Jira application and the MySQL DB, the Database proxy might be performing some logic/operation that is outside of Jira's control. Such an operation might be blocking the queries coming from Jira with the READ-COMMITTED isolation since this isolation level does not match the one configured in the MySQL database (REPEATABLE-READ). As a result, the SQL queries coming from Jira will be rolled back, the bulk operation that was initiated in the Jira application will fail to complete, and some errors related to issue/comment versions will be thrown in the Jira logs.

Solution

Our suggestions are to

• either reach out to the administrator of the proxy database, so that its configuration can be amended to allow the isolation level of the SQL transactions coming from the Jira application

• or remove the Database proxy located between Jira and the Database server

• or change the isolation level at the MySQL Database level to READ-COMMITTED, so that it matches the isolation level of the Jira SQL queries