cancel
Showing results for 
Search instead for 
Did you mean: 

Share: Upload new Version => InvalidNodeRefException: Node does not exist

mrks_js1
Star Contributor
Star Contributor

Hi

We have 1 corrupt document in our 5.0.d instance.

The issue can be reproduced like that:

  • User tries to upload new version in share (of this particular pdf)
  • => upload fails, every time.

log output:

Caused by: org.alfresco.service.cmr.repository.InvalidNodeRefException: Node does not exist: workspace://SpacesStore/a16e49b5-a516-4c1a-b85f-140990595ff9 (statusSmiley Frustratedtatus[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. 😕

1 ACCEPTED ANSWER

afaust
Legendary Innovator
Legendary Innovator

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.

View answer in original post

13 REPLIES 13

afaust
Legendary Innovator
Legendary Innovator

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.

mrks_js1
Star Contributor
Star Contributor

changes to the metadata of the document don't work either! Smiley Sad isn't there a prop cleanup cron that could be run?

afaust
Legendary Innovator
Legendary Innovator

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.

mrks_js1
Star Contributor
Star Contributor

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.