Labels from one @NodeEntity class incorrectly added to nodes of different @NodeEntity class

[Dev205]

Environment (Also verified with newer versions)

• Neo4j OGM Version: 3.3.5-
• Neo4j Driver Version: 4.4.19

Basic structure of classes

@NodeEntity
public abstract class BaseEntity {
    @Id @GeneratedValue
    private Long id;  // Neo4j internal ID
    private String name;
    private String workspaceId;
}

@NodeEntity
public class Product extends BaseEntity {
    private String productCode;
    private String category;
}

@NodeEntity
public class Document extends BaseEntity {
    private String documentId;
    private String type;
}

When using session.save() to update entities during the processing of the data, labels from one entity class are being added to nodes of a completely different entity class and not in the hierarchy.

Example:

A Document node (with label Document) receives additional labels BaseEntity and Product
This results in a node having labels: ["Document", "BaseEntity", "Product"]

This causes AmbiguousBaseClassException when querying:

org.neo4j.ogm.exception.core.AmbiguousBaseClassException: 
Multiple classes found in type hierarchy that map to: [Document, BaseEntity, Product]

Workaround
Changing from Neo4j internal IDs to UUID-based IDs resolves the issue:

@NodeEntity
public abstract class BaseEntity {
    @Id @GeneratedValue(strategy = UuidStrategy.class)
    private String id;  // UUID instead of Neo4j internal ID
    private String name;
    private String workspaceId;
}

After this change:

• Labels are correctly assigned to their respective entity types
• No AmbiguousBaseClassException occurs
• Nodes maintain only their correct labels

Just trying to figure out what might be wrong with the current processing as it reliably occurs with a small dataset. Are ids being reused? Is the session giving ids and merging etc.

I've tried fixing it various ways i.e. clear session, explicit new sessions, explicit labels etc. Nothing really seems to help me solve the cause of this. I don't mind using the UUID, i just want to know what the issue is.

Edit:
There is a delete during the processing of Document nodes, and when I remove this it seems to fix the occurrence of AmbiguousBaseClassException.

[meistermeier]

Thanks for raising this. Unfortunately I'm not able to reproduce the problem and created an example project from where you might could derive a reproducer: https://github.com/meistermeier/neo4j-issues-examples/tree/master/ogm-gh-1355

Tried various variation of interaction but all the time I ended up with exactly two labels on each node.

[Dev205]

I've tried reflect the code a bit better here https://github.com/Dev205/neo4j-ogm-issue-example/tree/main/demo

And I increased the created nodes which leads to this

[meistermeier]

Thanks for the reproducer. I saw the problem, then I tried some things, reverted back to the original state and now I cannot reproduce the problem anymore 😕
Yes, you are right that there might be something in Neo4j-OGM that is creating those wrong labels from a different branch of the hierarchy. But first I need to figure out how to enforce this behaviour again to analyse it.

[meistermeier]

Alright, I think I have an explanation of this behaviour. It's not really a bug in Neo4j-OGM but it's more that it is not aware of what the current state in the database is.
The DELETE statements will just remove entities in the database but Neo4j-OGM does not know about this change. As a consequence, it will still have a cached mapping of e.g. id: 100 -> :Document also after the deletion.
Now comes the Product save process and will create new products. Simplified, Neo4j decides to assign a previously used id (from a Document) and Neo4j-OGM will issue just an update/merge because it knows that the id (100) is in its cache and only add the information in the end. Also while I was testing this it might be more in the area around relationship caching (fromId -> toId) that this happens because I could not reproduce it when there where no relationships in play.
That's why also the workaround with UUIDs works, because it's not relying on the internal ids.
But in fact the deletion, or any custom query that does not "produce" any nodes to adjust the context to, does not write back to the session context/cache because there is no information available.
This would also be fixed by clearing the session, which worked fine for me. But then I would always recommend to load the parts of the graph you want to update prior modification.

[michael-simons]

We do have in fact checks for modifying queries and are clearing the session automatically

neo4j-ogm/core/src/main/java/org/neo4j/ogm/session/delegates/ExecuteQueriesDelegate.java

Line 135 in 9202d97

if (mayBeReadWrite(cypher)) {

Introduced in 4296c27

I tried your reproducer with both Neo4j 4.4 and 2025.10, if I add a sessionFactory.openSession().loadAll(Book.class); I immediately get your error.

[michael-simons]

so while we do have code in place that will detect updates outside the session to some extend, it can't deal with updates that will just nuke away entities it seems. needs some proper thinking here, that issue.

[meistermeier]

The session.clear() will get called with the deletes. Even a single, explicit session.delete for one Document entity will confuse the cache and lead to this situation and at the end of the test there is one ':Product:Document` node.