Hi,

If server fails to return correct datatypes for the basic Attributes, then things can fail. If the server is made with any proper SDK that should never happen.

I would need to see the actual log line output, hard to say almost anything from that LogRecord. And normally the logging backend would be anything else than java util logging (e.g. Log4j2 or logback etc.).

SDK 4.2.0 (https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html#version-4-2-0) fixes some issue where the new Attributes of OPC UA 1.04 were not fetched for AddressSpace.getNode(…). Additionally it tries to read DataTypeDefinitions (one of the new Attributes) over DataTypeDictionaries (“the old way” of describing them). If all Structures cannot be resolved with DataTypeDefinitions it will revert to reading DataTypeDictionaries.

The logging line that would come out of the LogRecord should list the Structures that could not be resolved (i.e. we need to read how they are encoded/decoded, this information is either provided by the DataTypeDefinitions or DataTypeDictionaries, or both, basically the DataTypeDefinitions is the preferred way, but not yet a lot of servers support that, however the dictionaries can be considered deprecated and probably in the future there will be servers that do support pre-1.04 so we need to start preferring the 1.04 way..)

Additionally it should be mentioned that resolving the structure types is a best-effort attempt. In OPC UA the data is entirely provided by the server and must be exactly correct, otherwise it wont work. We should of course log more, but generally speaking, there is a lot of places that can go wrong, if the model is not made with proper tools, such as UaModeler.

Is this the same server as in the initial post (i.e. one returning wrong data for (User)AccesssLevel)? Can you tell it’s manufacturer or what SDK that has been used to make it?

Can you check (with UaExpert) all DataTypes, do they _all_ define properly the IsAbstract Attribute either as true or false?

Basically the error would happen if a server incorrectly would just return a Null for this Attribute instead of proper true/false.

We should probably have a better error check in place there (so in that way it is a bug within the SDK), but basically if a server violates some basic assumptions that basically no server has broken before, we might miss a check here and there..