Log shows message is published but dapr side cannot receive it

[xky0007]

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.

OPC Publisher container log.

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

Desktop (please complete the following information):

• OS: Win 11
• Version 23H2

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]

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

[xky0007]

@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]

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]

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]

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.