Unsuccessful method call goes into infinite loop

[alxy]

Describe the bug

We are using the MQTT transport with the configuration api to trigger certain actions on our OPC UA server. One such action is a kind of ping request, that validates the connection settings are. The ping request reads a couple of server nodes like server name and current time. If we pass valid, credentials all is good and we recieve the values. If we pass wrong credentials (for example, a wrong password if uaser/password auth is used), the publisher goes into an infinite loop trying to send the request again, and again, and again to the server. Even if we fix the credentials afterwards and send another request, it doesn't respond. What make it worse is that it even stops responding to pings for other servers as well. The only option to recover from that situation is to restart publisher.

To Reproduce
Steps to reproduce the behavior:

1. Start opc publisher with mqtt transport and configuration api enabled
2. Send a payload with wrong credentials, wrong security policy, etc to the methods topic opc-publisher/methods/noderead (and setup a response topic to observe the result)

    {
      "Connection": {
        "Endpoint": {
          "Url": "opc.tcp://opcplc1:40000",
          "AlternativeUrls": null,
          "SecurityMode": 3,
          "SecurityPolicy": "http://opcfoundation.org/UA/SecurityPolicy#None",
          "Certificate": null
        },
        "User": {
            "Type": 1,
            "Value": {
              "User": "user1",
              "Password": "Wr0nG"
            }
          }
      },
      "Request": {
        "Attributes": [
          {
            "NodeId": "ns=0;i=2254",
            "Attribute": 13
          },
          {
            "NodeId": "ns=0;i=2261",
            "Attribute": 13
          },
          {
            "NodeId": "ns=0;i=2262",
            "Attribute": 13
          },
          {
            "NodeId": "ns=0;i=2263",
            "Attribute": 13
          },
          {
            "NodeId": "ns=0;i=2264",
            "Attribute": 13
          },
          {
            "NodeId": "ns=0;i=2265",
            "Attribute": 13
          },
          {
            "NodeId": "ns=0;i=2266",
            "Attribute": 13
          }
        ],
        "Header": {
          "Elevation": null,
          "Diagnostics": null,
          "Locales": null
        }
      }
    }

3. Notice that no result ever appears on the result topic
4. See error in the logs:

   [24-05-03 15:14:10.6689] info: Azure.IIoT.OpcUa.Publisher.Stack.Services.OpcUaClient[0]
         Session opc.tcp://opcplc1:40000_118036FF with opc.tcp://opcplc1:40000 changed from Connecting to Unauthorized
   [24-05-03 15:14:10.6689] info: Azure.IIoT.OpcUa.Publisher.Stack.Services.OpcUaClient[0]
         #2: Failed to connect opc.tcp://opcplc1:40000_118036FF [state:Unauthorized|refs:1] to opc.tcp://opcplc1:40000/: BadUserAccessDenied...

5. The publisher tries to connect to the server infinitely with the wrong credentials

Expected behavior
It should be possible to either configure a global timeout (via command line flag) for the publisher, or - prefereably - we should be able to set a timeout using the request payload. At the very least, the publisher should still accept new requests, even if some previous request did not return properly.

Additional:

• publisher Version: 2.9.6

[alxy]

To add some further information: When using the HTTP api, this does not happen. There is also no timeout (so the request has to be cancelled by the client), but once it is cancelled, the publisher accepts new requests to read other nodes. I assume this is a problem with how fundamentally MQTT and HTTP work. The fix imho is to add some timeout to the requests in either case.

[marcschier]

in 2.9.9, 3 timeouts can now be set on the request header: operation timeout (OPC UA service call timeout), service call timeout (a timeout for an individual OPC Publisher operation, and connection timeout (time to connect). These are not hard numbers though, e.g., the connection timeout and service timeout are additive, and connection and service timeout are reset if the connection is disconnected within a call. When using stream browsing via HTTP, timeouts are applied to each operation of the stream. These timeouts can also be set to defaults using command line.

[alxy]

@marcschier Can you link the PRs or commits where it was introduced for better transparency?