Unexpected: current version does not appear to be 1st version in the list

Description

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.

Troubleshooting

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

Information required

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.

Environment

ACS 4.0.1, Oracle 11g 11.2.0.1

Activity

Show:
Indy Sandhu
February 24, 2021, 3:02 PM

Ok, thanks .

Eva Vasquez
January 20, 2021, 3:49 PM

No problem, I’ll try to reproduce. Also tell me what the target version is the customer hoping to land on?

Eva Vasquez
January 20, 2021, 2:57 PM

where did you click ?

Eva Vasquez
January 19, 2021, 3:34 PM
Edited

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?

Mark Tunmer
January 8, 2021, 10:03 AM

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

Done

Assignee

Jamie Oswald

Reporter

Jamie Oswald

Labels

None

Security Issue

None

Escalated By

None

ACT Numbers

01014414

Premier Customer

None

Patch Attached

None

Prioritization Score

None

Delivery Team

Customer Excellence

Bug Priority

Category 2

Affects versions