Crucible review re-indexing fails with ObjectNotFoundException
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
The Crucible review re-index fails and the following error is written in the logs:
2020-12-08 19:05:42,983 ERROR [ReviewIndexer1 ] fisheye DefaultReviewItemIndexer$2-call - Error indexing reviews
org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [com.cenqua.crucible.model.CrucibleRevision#56023]
Diagnosis
In this log line above the error happened in a revision whose ID is 56023.
Connecting to the database and running the SQL query below doesn't return any results for that ID:
SELECT * FROM cru_revision WHERE cru_revision_id = 56023;
Cause
There is a database inconsistency causing this issue.
Workaround
The inconsistency needs to be cleaned from the database by:
- Shutting down Fisheye / Crucible
- Connecting to the database used by Fisheye / Crucible
Running these two DELETE commands in the order they show up below:
DELETE FROM cru_frx WHERE cru_frx_id IN (SELECT cru_frx_id FROM cru_frx_revision WHERE cru_revision = 56023); DELETE FROM cru_frx_revision WHERE cru_revision = 56023;
Replacing the revision ID accordingly.
- Starting up Fisheye / Crucible
- Right after the startup the instance should trigger a review re-index automatically - and from scratch, not from where it stopped - because the previous attempt has failed.
- Repeat these steps above for every similar error reported.
Note:
Whenever the error above happens the re-indexing halts, meaning that this error will only be written once in the log file per re-indexing attempt, so this may result in many re-indexing attempts from scratch if there are many inconsistencies.
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.