10-28-2016 06:31 AM
Hi
We have 1 corrupt document in our 5.0.d instance.
The issue can be reproduced like that:
log output:
Caused by: org.alfresco.service.cmr.repository.InvalidNodeRefException: Node does not exist: workspace://SpacesStore/a16e49b5-a516-4c1a-b85f-140990595ff9 (statustatus[id=839815changeTxnId=db0d014e-01f3-461a-ae3b-abb822dd651e, dbTxnId=399375, deleted=true])
which makes sense - since workspace://SpacesStore/a16e49b5-a516-4c1a-b85f-140990595ff9 does not exist!
I tried to figure out if something might be wrong with the index but index is looking good. (tried retry, fix, purge error nodes, reindex txns of error nodes)
This particular pdf document has ~150 versions. I can't revert older versions, can't copy or move the document.
That is the only difference I can see right now. Updating versions of other documents is working fine.
Can't find anything fishy about the node other than that it is broken. Preview works btw. 😕
10-28-2016 08:20 AM
Looks like the document in question has a reference to a tag that no longer exists and the TaggingService fails to check that before action on the onUpdateNodeProperties during the creating of the working copy. This could potentially be classified as a bug - a non-existent tag or category (or any d:noderef property value) will be automatically removed from results of the public API, but internally (onUpdateNodeProperties) they may not be. Policies such as the TaggingService either need to be able to handle this or the policy framework needs to be updated to avoid passing invalid NodeRef instances.
It would be interesting to know if you could force that kind of behaviour on a second document. E.g. create a tag, a new document, tag the document with the new tag, delete the tag (via Admin Tools) and try to upload a new version to the document.
10-28-2016 08:49 AM
A short-term fix could be done by either removing obsolete tag references from the database (transparent to end users and potentially more efficient) or by performing dummy-updates on affected documents. I.e. update the metadata via script API with trivial or even no-op changes. A save() on the ScriptNode API will always pass the entire property map through the public API which should remove any non-existing NodeRef values for d:noderef and d:category properties. There is a chance though that the TaggingService will act on the "before" state and still fail in this case.
10-28-2016 09:15 AM
changes to the metadata of the document don't work either! isn't there a prop cleanup cron that could be run?
10-28-2016 09:43 AM
Not that I know of. From my point of view this auto-remove of invalid NodeRef is a feature I would like to see removed. It is the responsibility of application code to check existence in potentially stale data before acting on it, i.e. the TaggingService should not be throwing hissy fits in the first place.
10-29-2016 04:21 PM
so, I can reproduce the issue.
a save() on the document does trigger the issue as well.
however, I can call clearTags() and that seems to get rid of the issue.
Tags
Find what you came for
We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.