Dev Panel doesn't update with rest of ticket

We received several reports from customers, that the problem occurred also in Fisheye/Crucible 4.5.1 and higher.
Version 4.5.1 contains a fix for a bug we found (missing OSGI import caused @PostConstruct to be not executed by Spring, resulting in events not being sent). We decided to re-open this issue in order to check if there is a second bug causing this faulty behaviour. If you happened to upgrade to 4.5.0, we still recommend upgrading to 4.5.1 or higher, as the fix delivered in 4.5.1 reduces occurrence factor.

Our investigation revealed that the new customer reports about missing data in the Development panel are caused by the problem with Jira synching mechanism. Crucible correctly pushes events about new commits as well as correctly responds to Jira queries about particular issue key. Therefore, a fix for cached data not being refreshed has to be implemented in Jira, please vote and watch the JSWSERVER-16760 bug report.

The JSWSERVER-16760 bug has been fixed and is pending public release in Jira
7.6.11, 7.13.1 and 8.0.0.

The fix only ensures that the problem won't happen again to new data. Existing data that got affected in an earlier version won't be fixed automatically. For example, the DevPanel still doesn't show up for some issues that have commit links, but if we make a new commit to the issue then all will show thanks to the fix.

Workaround for a single issue

In such a case, what we can do is to manually delete the fusion cached data related to the issue in the Jira database. For example, if you discover that issue ABC-123 is affected (it has 1 commit but DevPanel doesn't show), you may:

1. Run this REST call to confirm it has 1 commit:

   <FeCru_BaseURL>/rest/remote-link-aggregation/latest/aggregation?globalId=ABC-123
   

2. Run this SQL query in Jira db to confirm Jira has an outdated record of it (no commit):

   select * from entity_property where json_value like '%"ABC-123"%';
   

   For JIRA 7.9+, run this query instead:

   select * from AO_575BF5_DEV_SUMMARY where json like '%"ABC-123"%';
   

   If there're more than 1 entry, get the ID of the one whose property_key (or provider_source_id for JIRA 7.9+) is FeCru's applinks ID.

3. If the above are confirmed, it's safe to delete the db entry for it to be rewritten with up-to-date data:

   delete from entity_property where id = <ID from the above SELECT query>;
   

   For JIRA 7.9+, run this query instead:

   delete from AO_575BF5_DEV_SUMMARY where id = <ID from the above SELECT query>;
   

Workaround to flush the entire cache in Jira

1. Run the query to get the information about the app link in Jira:

   SELECT SUBSTR(a.property_key,16,36) as "Application Key", b.propertyvalue as "Application Name" FROM propertyentry a join propertystring b on a.id=b.id where a.property_key like 'applinks.admin%name';
   

2. Delete the app link from the Jira side
3. Delete the app link from the FeCru side
4. Take a backup of the Jira database
5. Stop Jira to make a DB update
6. Delete all entries relating to the FeCru app link from entity_property. For example, if "fa55abbf-804c-31fd-8d07-1878e61b9766" is the app-link for FeCru:

   DELETE FROM entity_property WHERE PROPERTY_KEY LIKE '%fa55abbf-804c-31fd-8d07-1878e61b9766%';
   

   For JIRA 7.9+, run this query instead:

   DELETE FROM AO_575BF5_DEV_SUMMARY WHERE JSON LIKE '%fa55abbf-804c-31fd-8d07-1878e61b9766%';
   

7. Re-install the app link between Jira and FeCru
8. Validate that issues now show updated commit information

Important notes on the workaround above

• The workaround must be tested on a copy of Jira before executing in production.
• We have observed that Jira issues will get added to the entity_property table as users browse them. At some point, Jira pulled changes for all issues from FeCru as well. This leads us to think this operation may be expensive and makes it safer to run the workaround in production outside of peak hours.
• A few hours after the workaround is run, we need to count the number of records from the query:

  SELECT * FROM entity_property WHERE PROPERTY_KEY LIKE '%fa55abbf-804c-31fd-8d07-1878e61b9766%';
  

Steps to reproduce.

1. Fisheye 4.5.0 JIRA version doesn't matter
2. Perform a smart commit with any kinds of tags of any size

Expected results.

As soon as the commits are available in Fisheye, the JIRA ticket is updated accordingly.

Actual Results

Everything is updated in JIRA except for the Dev Panel. It will take up to 30 minutes for the changesets to show up. After the first branch and commit are available, the number is not updated properly but if you click on the links, all of the branches and changesets appear as expected in the popup.

Workaround

N/A as of now. Clicking on the already available links will reveal the true information, but the first one there is no workaround.