Simulating faults with the Milo SDK

[vcatrici]

Hi! Is there a recommended way to simulate a fault in order to test the FaultListener functionality?

I noticed the Ua stack client has a default fault listener that refreshes the session if a fault is encountered. I am trying to write a wrapper over UaClient that emits a metric when the fault is received but I'm unsure how to easily test this.

The question is more of a general one but anything along these lines would be appreciated:

• how to write a server with Milo that simulates the fault
• what is considered a Fault (e.g. why is a Bad_TooManySessions not a fault but some other exceptions are?)
• any easy way to inject faults without writing code (e.g. interrupting the network connection)

Many thanks!

[kevinherron]

Try sending a ReadRequest with an empty array of nodes to read and see if that generates a ServiceFault.

A "service fault" is any response from a Server where serviceResult StatusCode in the ResponseHeader is not good.

[vcatrici]

Thanks! I've managed to generate the fault with the ReadRequest:

read(0.0,TimestampsToReturn.Source,listOf())

ResponseHeader(timestamp=DateTime{utcTime=133911927747630000, javaDate=Thu May 08 15:46:14 UTC 2025}, 
requestHandle=3, serviceResult=StatusCode{name=Bad_NothingToDo, value=0x800F0000, quality=bad}, serviceDiagnostics=null, 
stringTable=null, additionalHeader=ExtensionObject{encoded=ByteString{bytes=null}, encodingId=NodeId{ns=0, id=0}})

Sometimes a request yields a response with a service-level error. Other times only certain operations within a service request might return an error.

That's interesting, could you help with the following questions if you can?

1. is there any line of reasoning for why only certain operations do service-level errors?
2. why does Milo restart the session on Service level errors? Does this imply somehow that the current Session/SecureChannel is "corrupted"? E.g. the server treats sessions/channels that generated ServiceFaults differently to "well behaved" sessions and Milo is circumventing that scenario? Or is it simply the case that once a ServiceFault is returned, a well behaved client will restart a new session?
3. coming from an http service mindset, I'm wondering if these faults (Service or Operation level) can be mapped to 4xx (client) and 5xx (server) http error codes? I want to assess the health of a Milo instance and a connected OPC-UA server and if I track these faults as metrics, should they be weighted differently (e.g. operation level faults are less invasive than service level ones)?

Appreciate your time answering!

[kevinherron]

is there any line of reasoning for why only certain operations do service-level errors?

Anything that is a service level error is defined as such by the OPC UA specification. I'm not making these decisions arbitrarily.

why does Milo restart the session on Service level errors? Does this imply somehow that the current Session/SecureChannel is "corrupted"?

Not all service-level errors, just certain security- or session-related ones. The Session FSM needs to somehow detect that the Session has "disappeared", gone bad, got corrupted, or otherwise needs to create a new Session, when something funny happens on a Server that results in the Session no longer existing even though it wasn't closed explicitly by the Client. It's what ensures it transitions out of the Active state in these cases.

should they be weighted differently (e.g. operation level faults are less invasive than service level ones)?

I'm not sure if you can weight them differently or not. They're just a different granularity. Is a service call failing because you specified no nodes really worse than a service call that succeeds but has a bad operation result because e.g. you provided a NodeId that doesn't exist? I don't know... maybe?

[vcatrici]

I see, thanks! Based on my understanding of what you're saying I should not treat them differently.

If I want to emit metrics on any faults, I noticed the FaultListeners only check for UaServiceFaultExceptions in the maybeHandleServiceFault method. If I were to capture all faults, I would need to do something along these lines. This is a Kotlin class that overrides UaClient:

    override fun <T : UaResponseMessage> sendRequest(request: UaRequestMessage): CompletableFuture<T> {
        val future: CompletableFuture<T> = super.sendRequest(request)
        future.whenComplete( { response: UaResponseMessage?, ex: Throwable? ->
            // 1) handle service faults 
            // 2) handle operation faults
        })
        return super.sendRequest(request)
    }  

I'm wondering if it makes sense to change the current FaultListeners to ServiceFaultListerners to make this more explicit and potentially add addOperationFaultListener and/or change addFaultListener to cover both scenarios?

My use case is just metric emission and I would assume the per-operation faults are dealt with further upstream when calling read, browse, etc but just a thought.

[kevinherron]

It's already called ServiceFaultListener, not FaultListener. The methods to add/remove could perhaps be named to match exactly.

Intercepting entire responses to look for "operation faults", which aren't really a thing the way ServiceFault is an explicit thing in the spec, is probably not something I'm interested in. You couldn't even do it generically, you would have to know about every kind of response and do a bunch of instance of checks.

[vcatrici]

You couldn't even do it generically, you would have to know about every kind of response and do a bunch of instance of checks.

Makes sense, it would only be relevant for counting I suppose.