Betreff: VersionManager purging seems to have no effect

[curious2improve]

I am running Version purge as described in the docs https://experienceleague.adobe.com/docs/experience-manager-65/deploying/configuring/version-purging....

with settings of

versionpurge.paths = /content

versionpurge.recursive = true

versionpurge.maxVersions = 0

versionpurge.minVersions = 0

versionpurge.maxAgeDays = 1

to my understanding, this should delete all versions that are older than 1 day, in other words: only versions from yesterday are kept, anything else is gone.

Hoewever if I check my pages, I still see the same number of pages with the properties

jcr:baseVersion

jcr:versionHistory

jcr:predecessors

e.g. when I run this query, the number of results is the same

http://localhost:4502/bin/querybuilder.json?type=cq%3aPage&p.hits=selective&p.properties=jcr:path jcr:content/jcr:predecessors&p.offset=0&p.limit=1000&path=/content&property=jcr:content/jcr:predecessors&property.operation=exists&property.value=true

My assumption was that if all versions of a page are purged, the above-mentioned properties would be gone (as there should be no predecessors anymore).

When I use the purge tool of the classic UI /etc/versioning/purge.html for debugging, as suggested in the docs, I am seeing messages like this in the log output

A12 ABC /content/site/en/sustainability/abc/jcr:content

retained  V 1.1* Thu May 27 2021 14:12:17 GMT+0000

B14 XYZ /content/site/en/sustainability/xyz/jcr:content

retained  V 1.15* Tue Nov 02 2021 15:06:07 GMT+0000

 CC template /content/site/en/spotlight/template/jcr:content

retained  V 1.0* Fri Oct 16 2020 14:47:48 GMT+0000

These dates are clearly much older than my given threshold, yet they are not deleted.

When I check my error log, I see a lot of messages like

com.day.cq.wcm.core.impl.VersionPurgeTask Purged version 1.2 of /content/site/...

but the paths mentioned above are not among them (kind of makes sense if they are not purged).

What am I missing?
Also, assuming I want to purge ALL versions, e.g. on a lower test environment where I have no need for them, how can I best achieve that?

[somen-sarkar]

Hi, 

As per the  documentaion if the max versions value is less then 1 then purging is not based on the number of versions.  So having value as 0 may be creating some conflicts and keeping the versions.

• versionmanager.maxNumberVersions (int, default 5)
  On version purge, any version older than the n-th newest version will be removed. If the value is less than 1, purging is not performed based on the number of versions.

I have done a random testing by creating below configuration and looks like the versions are getting purged and only 1 latest version is kept after purging.  I feel atleast 1 version will be available. Play around with the configuration and let us know your findings on the same.

Thanks,

Somen

[curious2improve]

Yes, for values higher than zero the docs make sense and I understand what it does.

But I am trying to delete ALL versions, completely and immediately. As far as I can see, this is not possible with the builtin VersionPurge tool, and the documentation is unclear on what the behaviour is when both maxVersions and maxAgeDays are zero.

The best way is to set maxAgeDays to 1 and all other values to 0, then it should remove all versions but only after two days.

I have also discovered that there are additional issues with the versioning or at least the VersionPurge tool.

If there are two AEM Author instances, call them X and Z, and Z has a page with versions, and X has the same page (path) with versions

and a package is created with that page on X, uploaded to Z and installed - then there seems to be a potential for hickups in the versions that VersionPurge is not able to clean up.

Specifically: a package that includes a versioned page, then that page will have the jcr:uuid and mixinTypes = mix:versionable properties in the .content.xml file (package will not include older version as those are in /jcr:system/jcr:versionStorage which is not part of the package obviously).

But on the target system (with different versions for that page), AEM will repair/restore the jcr:baseVersion, jcr:versionHistory and jcr:predecessors properties which are not part of the package content.xml file.

In principle this makes sense, as that should set the version history of that page on the target machine - and should be consistent if successful.

But I can see that VersionPurge is struggling with some nodes that keep showing up in the logs, so at some point in time something was mixed up presumably due to content packages and duplicate uuids and now there is an inconsistency, either in the properties, and/or jcr:versionStorage and/or in the versionstore index (/oak:index/versionStoreIndex)

So the really interesting question is: how can the Version Storage and index be reset completely, in a clean way?

[curious2improve]

This post also shows a similar issue:

https://stackoverflow.com/questions/66607859/removing-versions-from-versionstorage-for-deleted-pages... 

Basically the version storage has "orphaned" versions of deleted pages, because the pages no longer exist. The out-of-the-box VersionPurge does not clean those either.

The local versions can easily be checked with
http://localhost:4502/bin/querybuilder.json?type=nt%3aversionHistory&p.hits=selective&p.properties=j... 
it will quickly show a lot of stuff that should no longer be there