[Feature Request] Surface OT device errors via mRPC protocol

[koepalex]

Usecase:

As a developer writing connectors
I want to be able to communicate protocol specific errors (like Bad_NodeIdUnknown for OPC UA)
So that I can inform the initial caller, that the request was correct, the application (customer and connector) worked correctly but still the call wasn't successful.

Todo:

• Extend CommandStatusCode with BadGateway (502)
• Add new AkriGatewayException allowing the connector to define a custom status message
• Extend AkriSystenProperties with IsGatewayError (proposal ReservedPrefix + "gwErr")
• Update CommandExecutor.cmdFunc to catch the AkriGatewayException and pass IsGatewayError along with the status message thru GenerateAndPublishResponse method

[lt72]

This should definitely be considered as we want max visibility into the error from the producer side.
Assign to @avishekpant and also @ryanwinter fyi.

[avishekpant]

We are actively looking into it and should have an update soon.

[koepalex]

@avishekpant any updates on this topic?

[ryanwinter]

Looking into this, will give an update today.

[ryanwinter]

We are tracking this internally as part of an error overhaul to support custom errors.

[clecompt-msft]

In order to support fully customizing (and strongly typing) application-level errors, our current plan of record is actually to remove them from the protocol layer entirely (ADR 15). Instead, they should be defined as part of the response payload. In order to support this in a more ergonomic manner, DTDL will be extended to indicate which portions of a response represent normal vs. error payloads (ADR 19, currently in PR), allowing codegen to split and return them as appropriate.

[koepalex]

@clecompt-msft
In OPC UA (and other "higher-level" protocols like Bacnet/IP) the request/response payload is already defined within the address space of the server, we can't extend that.

Those protocols provide additional information (application errors, protocol errors) as part of their protocol headers. If we don't define a common way to handle this, each connector might do that slightly different, which would lower the benefit of using mRPC and the SDK from end user perspective.

Please keep also in mind that those "higher-level" protocols will not use code generation, as they dynamically learn the address space of the server while connecting to them.

[jrdouceur]

Those protocols provide additional information (application errors, protocol errors) as part of their protocol headers. If we don't define a common way to handle this, each connector might do that slightly different, which would lower the benefit of using mRPC and the SDK from end user perspective.

This is a very interesting point. Quite a while back, the decision was made not to provide any modeling for headers. Payloads are fully modeled, but headers are fully ad hoc. I'm not clear on the motivation behind this decision, and it is certainly changeable from a technical perspective, but it would be a fair amount of work to make such a change. There is no support, no design, and not even a clear set of requirements. If we think this is something to consider, we should perhaps start a requirements doc for the feature.

[jrdouceur]

@koepalex, I've been thinking about this over the weekend, and I'm not sure I understand the requirements. At the top of this thread, you wrote:

• Extend AkriSystenProperties with IsGatewayError (proposal ReservedPrefix + "gwErr")

But in a later response, you wrote:

In OPC UA (and other "higher-level" protocols like Bacnet/IP) the request/response payload is already defined within the address space of the server, we can't extend that.

Those protocols provide additional information (application errors, protocol errors) as part of their protocol headers.

Are the headers already defined by OPC UA? Or do we have the freedom to define headers as we wish?

[koepalex]

The headers are already defined in OPC UA service call definitions, for OPC UA server <> OPC UA Connector interaction, and this error would need to be transmitted to the initial caller which used mRPC

[jrdouceur]

Since we currently have no facility for modeling headers, I'm not sure what we can do about this. But for due diligence, can you post a pointer to the header definitions? I'd like to take a look.