Unexpected: current version does not appear to be 1st version in the list
While testing an upgrade of ACS 4.0.1 it was noticed that certain content became irretrievable with the error "Unexpected: current version does not appear to be 1st version in the list" in version 4.2.8, the first stage of the upgrade. Attempts have been made to revert the versions but this did not correct the issue. This was also observed in 5.2.7 as we advised customer to progress to a supported platform and see if the issue persisted, which it did. Reverting the content was also attempted on 5.2.7 without success.
In Explorer 4.0.1 and 4.2.8, there was no issue noticed in the UI.
When Share was used, this is where the issue is noticed, but in 4.2.8 (and 5.2.7) not in 4.0.1 Share.
Further investigation by way of DB query (attached as Query.txt) showed that the DBID of version 1.0 was higher in value than version 3.0 (in Query.txt)
Attempting to revert the versions through Share UI failed in 4.2.8 and 5.2.7
A dump of the 4.0.1 DB is available on FTP at /companies/e/ev/evoltia
Attachments 4.0_1.png and 4.0_2.png show an affected node properties (nodebrowser) in 4.0.1
Attachments 5.2.7_1.png and 5.2.7_2.png show the same node properties (nodebrowser) in 5.2.7
The volume of affected content is too high and is also spanning back to 2016 and as such we want to explore any way of correcting the versioning by altering the DBID or somehow correcting this issue at the DB level, by SQL, API or script.
ACS 4.0.1, Oracle 11g 220.127.116.11
Ok, thanks .
No problem, I’ll try to reproduce. Also tell me what the target version is the customer hoping to land on?
where did you click ?
Several attempts were made to reproduce the issue OOTB with no success.
Importing the customer’s DB I was able to verify the non sequencial ID’s so I managed to directly change the ID’s in my local database so I could verify the impact.
Having non-sequencial alf_node id’s for my version nodes did not produce any difference on the way they are displayed in share in version 4.2 so I analysed the code to see exactly how these versions are retrieved.
Turns out that the versions are ordered by association ID, not their node id: id of the association of the version node to the versionHistory node in alf_child_assoc
I started my repo on version 4.0 and it seems that in this version the alf_child_assoc id’s are independent from the child node id, so mine were in sequential order and I had the correct results displayed. This is not the case apparently for older versions: in the customer’s database the alf_child_assoc id is an exact match to the child node id, in mixed order.
I was able to manually change my alf_child_assoc id’s and finally verify the problem in Share.
I found later that this is a known issue [MNT-226] with repo’s before 4.x and can be fixed by declaring a version comparator to be used instead:
As I understand it this comparator uses the last modification date to sort versions instead of using the alf_child_assoc ID’s.
After adding the above config in my alfresco-global.properties file and restarting my instance, the versions were correctly displayed again.
Unfortunately this fix does not seem to be documented anywhere (not even in the original MNT). I would expect it to be documented here: https://docs.alfresco.com/4.2/concepts/global-props-upgrade.html with something like:
version.store.versionComparatorClass - Optional Comparator<Version> class name to sort versions. Set to: org.alfresco.repo.version.common.VersionLabelComparator if upgrading from a version that used unordered sequences in a cluster.
Should we raise a DOCS issue for this or is it enough that support has this info for future enquires?
In 4.0.1, both Explorer and Share showed the version history as expected.
In 4.2.8/5.2.7, Share seems to show the version history in the order of descending node id. In the case of some nodes, an increasing version number doesn’t track increasing node id’s, causing the version history to be out of order and exceptions when trying to access the content.
With the number of nodes affected by this, the customer is looking for an effective way to correct this in their environment, either before they upgrade from 4.0.1, or once they get to 5.2.7