Loading Custom Structs using Dynamic Type Loader with missing type_definition and non-Numeric NodeId

[porquey]

Hello,
I have been experimenting with custom dynamic structures via the example code in the samples: https://github.com/FreeOpcUa/async-opcua/blob/master/samples/custom-structures-client/src/bin/dynamic_client.rs

In my example I have the following code to load in the dynamic structs:

        let type_tree = DataTypeTreeBuilder::new(|f| f.namespace <= 4)
            .values_per_read(100)
            .build(&session)
            .await?;
        println!("{:?}", type_tree);
        let loader = Arc::new(DynamicTypeLoader::new(Arc::new(type_tree)));
        session.add_type_loader(loader);

From my limited testing and debugging I see that it can load the types and encoders for dynamic types registered by the OPCUA server when the NodeId of the types (and perhaps the variables) are Numeric.
However in our CODESYS generated OPCUA Server, the custom types are created with NodeId Identifier: String.

The above code example prints the type_tree, and I can see that for the dynamic_client.rs example, it can populate the struct_types, enum_types and encoding_to_data_type fields correctly.
When I repeat the same code against the CODESYS server, it iterates through the data type nodes such as:

NodeId { namespace: 4, identifier: String(UAString { value: Some("|type|CODESYS Control for Linux SL.Application.extractionAPI") }) }

But the type_tree contains empty struct_types, enum_types and encoding_to_data_type fields.

I wonder if this is a known limitation of dynamic type loader, or is expected behaviour according to OPCUA spec, and whether CODESYS is doing something unique with their server.

At the minimum, it would be great if types that do not have a registered encoder can still return the raw binary, rather than panicking.

Originally posted by @porquey in #132

[einarmo]

AFAIK the dynamic type loader does not concern itself with node ID type at all. Could you get some log output using something like env_logger?

As for a fallback, that is indeed something I've wanted to do. It is totally possible to do with the current type loader implementation, though it will be a little fiddly.

[porquey]

I see, at initial glance, the main noticeable difference was with NodeId type. Here is the log when I try to read the node variable after loading the dynamic types:

[2025-08-05T16:48:04Z DEBUG opcua_client::session::services::view] session:1 browse, success
[2025-08-05T16:48:04Z INFO  main] Reading node: ns=4;s=|var|CODESYS Control for Linux SL.Application.StationInfrastructure.StationInfrastructure.API.command
[2025-08-05T16:48:04Z DEBUG opcua_core::comms::chunker] Cannot decode message ReadResponse_Encoding_DefaultBinary, err = Error { status: BadDecodingError (2147942400), request_id: None, request_handle: Some(4760), context: "No type loader defined for ns=4;s=|enc|CODESYS Control for Linux SL.Application.CommandRequest" }
[2025-08-05T16:48:04Z ERROR opcua_types::encoding] BadDecodingError: No type loader defined for ns=4;s=|enc|CODESYS Control for Linux SL.Application.CommandRequest
[2025-08-05T16:48:04Z WARN  opcua_client::session::event_loop] session:1 Transport disconnected: BadDecodingError
Error: BadConnectionClosed

When inspecting the type_tree under node id=86, I can indeed see the type nodes for the above variables.
And can verify that with the Python library (https://github.com/FreeOpcUa/python-opcua), I can encode and decode the dynamic types from the server.

[einarmo]

I'm more interested in what happens before that, when you are actually loading the dynamic types. Getting an empty type tree indicates that something went wrong while building the type loader.

[porquey]

Ok I tried to dive deeper into the issue and here are my findings.
During build() of the type tree, I can see the code manages to get to this line, for the type node in question: https://github.com/FreeOpcUa/async-opcua/blob/master/async-opcua-client/src/custom_types/mod.rs#L138

In this function it invokes parent_ids.get_data_type_variant(), which invokes id.as_data_type_id(), which returns an Err(NodeIdError).
Looking into the implementation of as_data_type_id:

async-opcua/async-opcua-types/src/node_id.rs

Lines 777 to 784 in 6167208

	pub fn as_data_type_id(&self) -> std::result::Result<DataTypeId, NodeIdError> {
	match self.identifier {
	Identifier::Numeric(id) if self.namespace == 0 => {
	DataTypeId::try_from(id).map_err(|_| NodeIdError)
	}
	_ => Err(NodeIdError),
	}
	}

Here it tries to match the node identifier to Numeric(id), but in our case it is String(UAString(s)). I'm not so familiar with the OPCUA protocol, and am not sure what data_type_id it should return in this case, or whether there is another way to infer whether this data_type is a struct, primitive or enum (perhaps based on VariantType?).

[einarmo]

Hm. I don't think that is it. What that code does is recursively iterate up through the data types to find which built-in type they descend from in the type hierarchy. Note that it does if let Ok(t) = id.as_data_type_id(), so it handles the error returned from as_data_type_id locally.

It'll return an error for your type, sure, but then it will keep going

let parent = self.parent_ids.get(id)?;
self.get_data_type_variant(parent)

recursively traversing through its parent.

Eventually this must hit a built-in OPC-UA type, which are all numeric.

[porquey]

I see, thanks for explaining. Let me do a bit more digging around this type_tree generation and then get back to you.

[porquey]

So I inspected the content of type_data variable after it has been populated in this line: https://github.com/FreeOpcUa/async-opcua/blob/master/async-opcua-client/src/custom_types/mod.rs#L276

One of the type nodes generated from CODESYS, and it's RawTypeData looks like this. Could it be due to the fact that type_definition is None? Is this expected to be always filled?

 NodeId {
        namespace: 4,
        identifier: String(
            UAString {
                value: Some(
                    "|type|CODESYS Control for Linux SL.Application.Command",
                ),
            },
        ),
    }: RawTypeData {
        type_definition: None,
        is_abstract: false,
        encoding_ids: Some(
            EncodingIds {
                binary_id: NodeId {
                    namespace: 4,
                    identifier: String(
                        UAString {
                            value: Some(
                                "|enc|CODESYS Control for Linux SL.Application.Command",
                            ),
                        },
                    ),
                },
                json_id: NodeId {
                    namespace: 0,
                    identifier: Numeric(
                        0,
                    ),
                },
                xml_id: NodeId {
                    namespace: 0,
                    identifier: Numeric(
                        0,
                    ),
                },
            },
        ),
        name: "",
    },

[einarmo]

Is it a structure? If yes, then indeed, that is the problem. The dynamic type loader is meant to deserialize structures by reading their definition from OPC-UA. This doesn't appear to have a type definition, so the dynamic type loader can't handle it.

[einarmo]

If what you really need is just a fallback, then I do have some ideas for how to do that. It's something that I've planned to implement. Of course, that wouldn't actually let you read these structures in a meaningful way, you'd just get a binary blob.

[porquey]

Yes it is a structure that is generated by the Codesys program, so I don't think we have control over how it populates the TypeDefinition.

The fallback is also a potential workaround, since we know exactly what to expect at each node.

Although I am curious how we were able to decode the structs in our Python clients, when the TypeDefinition is None. Inspecting their StructGenerator, it seems to be able to infer the nested field types and names from the Server's XML: https://github.com/FreeOpcUa/python-opcua/blob/fdf5f3c6c8655c90b0d36ce6a8db54749e8daeb4/opcua/common/structures.py#L215-L244

[einarmo]

Oh, yeah, that's basically what we do in codegen. If you have the XML, you can generate types, though our codegen only supports numeric node IDs... We could support string IDs. This is just the first time I've seen them in the type hierarchy.

Not sure what you would do here, ideally. Depending on how many of these types there are you could implement your own TypeLoader. It's not quite as straight-forward as in https://github.com/FreeOpcUa/async-opcua/blob/master/samples/custom-structures-client/src/bin/native_client.rs, since you can't use the StaticTypeLoader shortcut, but it is possible to do.

In that sample we create a struct and call the #[ua_encodable] macro on it, to generate decode/encode implementations.

[porquey]

I see, so with the Codegen can do what Python lib is doing, but not with String NodeIds yet?

Can you elaborate on why I couldn't use the StaticTypeLoader shortcut?

[einarmo]

The StaticTypeLoader shortcut is the part that requires numeric node IDs, though we could probably change it to be generic.

There's nothing really preventing us from supporting non-numeric node IDs with codegen, but it would take a little work to implement.

The core of all this is the TypeLoader, which is a trait you can implement that should decode a type from the stream if it recognizes its encoding ID. There is nothing preventing you from implementing that in whatever way you need. StaticTypeLoader is just a convenient shortcut to make it slightly less verbose.

[porquey]

Thanks for the continuous prompt support.
Going back to the topic on whether a client could dynamically load the structs from information in the OPCUA Server, even if DataTypeDefinition field is None. I want to dig deeper on how other clients/applications are still able to do it, despite this being missing.

When connecting to our server via UAExpert, I inspected the following nodes (which have similar String NodeId) for custom struct in question:

• Variable node (|var|)
  • NodeClass: Variable
  • DataType: Application.CommandRequest (custom struct)
  • Value: Fully decoded instance of custom struct (command, command_id, command_source)
  • References:
    • HasLocalVar: fields of struct
    • HasTypeDefinition: BaseVariableType
• Type node (|type|)
  • NodeClass: DataType
  • DataTypeDefinition: BadAttributeIdInvalid()
  • References:
    • HasEncoding: Default Binary
• Encoding node (|enc|)
  • NodeClass: Object
  • References:
    • HasDescription: Application.CommandRequest
    • HasTypeDefinition: DataTypeEncodingType
• Description node (|desc|)
  • NodeClass: Variable
  • DataType: String
  • Value: Application.CommandRequest

Screenshots of UAExpert for inspected nodes:

Do you have some idea on how UAExpert may be able to load these structs and read/write to them from this information?
Is there anywhere else I can inspect/browse to provide more information?