Addressing truncated change log or rollback detected errors

When you index your lifecycle application data, you might encounter TRS validation errors in Lifecycle Query Engine. These errors usually occur when the application is offline for some time, or if the application is reset.

Problem

Following are two parts to indexing a Tracked Resource Set (TRS):
  1. Baselog indexing occurs when a TRS is added to Lifecycle Query Engine. Baselog indexing fetches the current set of resources from the application.
  2. TRS Changelog processing occurs after Baselog indexing when Lifecycle Query Engine frequently checks with the TRS for any changes, and updates them while indexing.

During changelog processing, Lifecycle Query Engine validates the TRS by looking at the last processed ChangeLogEvent. If the last processed ChangeLogEvent from the application matches the last processed ChangeLogEvent Lifecycle Query Engine indexed, then the change logs are processed. If the last processed ChangeLogEvent does not match, then the TRS validation fails with a TruncatedChangeLogException.

These failures typically happen because an application has reset its ChangeLogEvents and they no longer match the information that is indexed through Lifecycle Query Engine. The failures can happen if the application TRS is rebased or reset. The only way to recover from a RollbackDetectedException or a TruncatedChangeLogException error is to re-index the application TRS.

Solution

The only way to recover from a RollbackDetectedException or a TruncatedChangeLogException error is to re-index the application TRS. It is expected that after an Engineering Requirements Management DOORS® Next rebase, you must re-index the TRS in Lifecycle Query Engine.
Notes:
  • If during indexing, you encounter the RollbackDetectedException or TruncatedChangeLogException error, and it has many skipped resources, do not try to re-index the data provider. Investigate and address the skipped resource issue. When the resource issues are resolved, re-index the data provider.
  • If you encounter that the TRS event is present in the base, and hence it is present in TRS, then re-indexing fixes it. If the TRS event disappears from the Changelog, then it is not present in the base. It means that the TRS event is not present in the TRS feed and hence reindexing does not help.
  • If DOORS Next or IBM® Engineering Test Management resources has a data gap and the Data providers are displayed up to date in Lifecycle Query Engine, then the TRS validation must be done. TRS validation can be first done on the Data provider side (DNG or Engineering Test Management application) and then on the Data consumer side (Lifecycle Query Engine application). Validation is faster than re indexing. If validation does not solve the problem, only then opt for re indexing.