Amir Zuker (CV) Thanks for reaching out! It's a great question.
Can we configure or control the PUBACK-related behavior in Azure IoT Edge and reduce the time it takes it to send the PUBACK back?
According to the information you provided, it seems that when the Edge is offline and then reconnects, it takes a long time to send the PUBACK back, which causes the device to resend messages and results in duplicates in the other end.
You can try to reduce the time it takes for IoT Edge to send the PUBACK back by increasing the keep-alive interval or the retry interval in the device configuration.
Are there any other suggestions that we should consider in terms of dealing with duplicate messages? We know we can implement different kinds of de-duplications post Hub flows but that too is sub-optimal, and we would like to make it so it doesn't happen from the device end in the first place (not at this rate anyway).
For dealing with duplicate messages, you can implement different kinds of de-duplication post-Hub flows, such as using a unique identifier for each message and checking for duplicates before storing the message in CosmosDB.
You may want to consider develop a mechanism on the device side to detect when the Azure IoT Edge is offline and buffer the messages until the connection is re-established. This can help prevent duplicates from being generated in the first place. For example, you could have the device buffer messages locally in a queue until it receives a PUBACK from the Azure IoT Edge, confirming that the message was successfully delivered. This can help ensure that messages are not sent multiple times when the Azure IoT Edge is offline
Also, see Enable duplicate message detection for an Azure Service Bus queue or a topic