Hi,

I would label it as an interesting bug… hmmm..

A workaround could be to delete that HasTypeDefinition reference and add the correct one manually (since the UaNode itself was of the proper type, just the reference is wrong, i.e. the java type doesn’t define the HasTypeDefinition, skipping some details of why). But other than that it needs fixing in the SDK.

Basically the “more subtype” one should override the Reference (this logic is somewhat complicated i.e. we do the createInstances node-based not java-based as it wont work like that since instancedeclarations are allowed to override stuff), but maybe that doesn’t happen properly (though we did get that one for the node’s type… which is a bit odd). Also we can reproduce this here.

So, seems some of the very old internal logic relies on HashSet iteration order, which is bad (thus this can happen randomly and also might depend on java version, as the iteration order is java internal implementation). Basically the HasTypeDefinitions were added in the wrong order so the super-type-ones did override the correct one. We’ll try to fix this in the next release.

Also for the workaround, there is no need to delete the reference, just add the new one and it will replace the wrong one.

P.S.
Probably the logic could use some more updates as we did pick up the correct UaNode type. But in general the HasTypeDefinition cannot be java-class based, as the generated classes can also represent subtypes, if those models are not generated, i.e. for a given TypeDefinition node the “most-subtype-generated-one” will be picked for the UaNode implementation.