These exceptions can be transient, therefore retryable, or not.
For the C# SDK, the default RetryExponential policy, inherits from the abstract class RetryPolicy.
If an exception is transient, it will be retried following the defined policy, otherwise it will be immediately thrown.
In this application implementation, whenever an exception will raise, it will report to the SubscriptionMonitor.
If there are multiple non transient exceptions, there must be something wrong and Kubernetes should kill the pod.
If there are transient exceptions, we should try to understand if the application can recover in the grace period. Therefore, at its startup, the SubscriptionMonitor calculates how many exceptions will there be, as a maximum, given the number of possible retries in the defined grace period.
WARNING: The logic of this sample solution is depending on the specific implementation of the RetryExponential retry policy. If that changes in the future, the code may break and stop working as expected.
Even if the suggested approach is working, other alternatives should be considered.
One alternative could be sending an heartbeat message to the topic. If that will not affect other applications, your health check should be based on the receipt of the heartbeat.
This would ensure the liveness of the underneath connection and the proper acceptance of the message.