Azure / Industrial-IoT

Azure Industrial IoT Platform
MIT License
523 stars 214 forks source link

Log shows message is published but dapr side cannot receive it #2222

Closed xky0007 closed 4 months ago

xky0007 commented 5 months ago

Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

  1. Run OPC Publisher and dapr side car
  2. Change the subscribed OPC UA node value
  3. Check the dapr log and pub/sub component database used in dapr
  4. Container OPC Publisher cannot send data to dapr

Expected behavior Dapr log shows the publisher called the pub/sub service

Screenshots

Run code directly.

image

OPC Publisher container log.

This dapr log is for OPC Publisher running from code directly. And OPC Publisher log doesn't show Advancing steamxxxxx

image

Desktop (please complete the following information):

Additional context

How can I check the response when calling dapr pub/sub service? And if I can add it by myself, how can I build the project to a docker image? I cannot find the doc.

Thanks!

xky0007 commented 5 months ago

The log shows sent successfully. But no receive log on dapr side and db. image

xky0007 commented 5 months ago

@marcschier Hi, I think this is a bug. Because this log shows Messages successfully sent, but on dapr side log, it seems no API has been called.

Thanks.

marcschier commented 4 months ago

Whether you see the "Advance..." log is shown if you have command line option --da|deferredack on. I recommend to keep it off, no matter, it does not have any bearing on the transport.

Could it be an issue with the host name that publisher to call the GRPC endpoint on? See issue #2235.

Ultimately if the GRPC publish call to DAPR endpoint comes back green, publisher decides the publish was successful. But it is possible that there is a Dapr issue at play too.

marcschier commented 4 months ago

There is not much that can be logged on the Dapr API side, the PublishEvent SDK API returns just a Task. But I will add an option to the Dapr connection string validate the health of the sidecar before accessing and throw exception on publish if side care is unhealthy. I doubt this is helping, I would expect grpc call to also throw in that case, as there is no endpoint.

marcschier commented 4 months ago

The dapr connection string can now take an extra boolean value which will cause the dapr publish call to first check on the health of the side car. If the side car is not healthy, and exception is thrown which can be observed in the OPC Publisher logs. See https://github.com/Azure/Industrial-IoT/blob/35312eb58984dc1187581cd5e712f48c7d4573cd/docs/opc-publisher/commandline.md?plain=1#L352.