[Bug community and Enterprise] The node just created with the java service does not show up on the database

[p4535992]

DETAILS ENVIROMENT

ALFRESCO_CE_TAG=7.4.2 (Community and Enterprise)
SEARCH_CE_TAG=2.0.8.2
SHARE_TAG=7.4.2.3
ACA_TAG=4.2.0
POSTGRES_TAG=14.4
TRANSFORM_ENGINE_TAG=5.1.1
ACTIVEMQ_TAG=5.17.1-jre11-rockylinux8

Here the piece of code for create the node :

TRANSACTION 1 CALLED BEFORE TRANSACTION 2

RetryingTransactionCallback<NodeRef> callback = 
new RetryingTransactionCallback<NodeRef>() {
           @override
           public NodeRef execute() throws Throwable {
             logger.debug("Ensure that we get fresh node references");
             nodeDAO.setCheckNodeConsistency();
      NodeRef createdNoderef = **{DO SOMETHING}**;
                              if(!nodeService.exists(createdNoderef)){
       throw new AlfrescoRuntimeException("The node '"+createdNoderef +"' not exists...");
}
      return createdNoderef;
           }
         };  
RetryingTransactionHelper txnHelper = 
transactionService.getRetryingTransactionHelper();

txnHelper.setRetryWaitIncrementMs(1000);
txnHelper.setMaxRetries(3);

NodeRef createdNodeRef = txnHelper.doInTransaction(callback, false, true);
if(!nodeService.exists(createdNoderef)){
       throw new AlfrescoRuntimeException("The node '"+createdNoderef +"' not exists...");
}
log.info(“Created with success the node ‘”+createdNodeRef+”’”);

TRANSACTION 2 CALLED AFTER TRANSACTION 1 VIA REST API (or Action or anything in a different transaction)

NodeRef checkCreatedNodeRef = ...;
if(!nodeService.exists(checkCreatedNoderef)){
       throw new AlfrescoRuntimeException("The node '"+checkCreatedNoderef +"' not exists...");
}
log.info(“Check created with success the node ‘”+checkCreatedNodeRef+”’”);

The variable “createdNodeRef” contains the information of a nodeRef created by the Alfresco service, where in a subsequent (and separate) transaction the function “nodeService.exists(createdNodeRef)” returns false and the node does not appear to us even in the database and the binary does not appear in the content store.

We specify that we have no exceptions of any kind when executing the code within the transaction.

We highlight that in the code under “DO SOMETHING,” there are no bypasses of permissions (if we exclude those under Alfresco services) through the “RunAs” mechanism, or disabling behaviors through Alfresco's “BehaviourFilter.”

I was able to get a piece of code where this behavior occurs 100% of the time I get a nodeRef as result form the java code, but when I call it later via rest api it tells me it doesn't exist .. but then why was I returned a nodeRef as result ?

It can't be a concurrency problem because it's on my test machine where only I work... it gives me the idea that it's a problem with Alfresco's nodes transaction cache, does anyone have any idea what could be causing the behavior of these “ghost nodes” ?

[AFaust]

@p4535992 I must admit that even after going over it a couple of times, I understand much too little to even begin trying to understand/analyse this if I wanted. If you can reproduce this 100%, can you provide the minimal code to reproduce this as an AMP with source attachment? With snippets there are always a lot of assumptions to be made, i.e. is the outer code running in a web script with its own (read-committed) transaction? And any of such assumptions could change the behaviour and prevent being able to reproduce the issue.

[p4535992]

Unfortunately, I also couldn't understand why these “ghost nodes” (that's what I call them now) occur and all cases are tied to customer code flows that I cannot share.

I can tell you that I had a couple of cases where the action, webscript, rest api told me that it was creating nodes and I got the nodeRefs, but then when I looked for them in the database, they didn't exist, as if it had rolled back without giving me an error.

I should also point out that these are installations in which customers often put their own flows and then don't understand why the code don't work with strange permission bypasses, even though Alfresco should manage them.

We had an “important” customer with the enterprise version who was losing documents and couldn't understand why (even today, I still don't understand). They also opened a ticket with Alfresco support and consulted a Postgres specialist for any database-related issues.

Their use case was that they created nodes invoking a java code (a simple webscript) that returned the nodeRef of the created document as a result, and it worked 100% of the time, but when in a different transaction, the content of the document was requested, it was not actually present in either the database or the content store.

Not fully understanding why Alfresco was giving us a nodeRef that then told us it didn't exist, the solution I came up with was “ugly but simple,” which was to create a second separate “check” action that was invoked from the client as a request immediately after the "insert" jaca code to verify the actual existence of the node, and in case of error, they repeated the same “insert” java code, which then worked.

There was also a "very strange" use case of a customer who, after endless analysis of the code, I discovered that the cause of the silent rollback of his code was the personService. I tried replacing it with the nodeService, and it worked.

This code was the cause of the silent rollback, no error anywhere console, database, ecc.

PersonInfo personInfo = personService.getPerson(nodeRefUser);
String firstName = personInfo != null ? personInfo.getFirstName() : null;
String lastName = personInfo != null ? personInfo.getLastName() : null;	

This code done with the nodeService instead was ok

Map<QName, Serializable> props = nodeService.getProperties(nodeRefUser);
String firstName = (String)props.get(ContentModel.PROP_FIRSTNAME);
String lastName = (String)props.get(ContentModel.PROP_LASTNAME);

If my memory serves me correctly (forgive me, it's been a while), I managed to replicate the behavior of “ghost nodes” with this open source project https://github.com/boneill/alfresco-sync/ by replacing the value of the variable synch.scheduledjob.runasusername=admin with synch.scheduledjob.runasusername=System.