After Disaster Recovery Dapr is not working properly for Process Mining and Task Mining

After a Disaster Recovery, Dapr is not restored properly, and the certificates needed by dapr to provide services for Process Mining and Task Mining are incorrect. The dapr, processmining, and taskmining applications appear to be healthy first, but will then go back to progressing state and the environment becomes unstable. When logging in to Process Mining or Task Mining, the application may not load, or return unexpected errors.

This page describes the steps you should take to resolve the issue.

Checking the status for dapr

Follow these steps to check whether dapr is working properly.

Open ArgoCD and go to Applications.
Select the processmining application card to open the processmining app details tree.
Locate the processmining pods and check the number of containers in the pod.
For a proper working of processmining there must be 3 containers in the pod. In the above example, there are 2 containers in the pod, which means that there is one container missing.
Open the pod and select the LOGS tab. Select processmining to see the available logs.
Check whether the daprd log file is present. If there is no log file for dapr, this indicates that dapr is not configured properly.

Overview of the steps

Delete all dapr secrets and the mutatingwebhookconfiguration.
Resync all dapr secrets and the mutatingwebhookconfiguration.
Restart dapr-sentry deployment and wait to the deployment is finished.
Restart dapr-operator deployment and wait to the deployment is finished.
Restart dapr-sidecar-injector deployment and wait to the deployment is finished.

Below is a detailed description of the steps.

Deleting dapr secrets and the mutatingwebhookconfiguration

Go to Applications in ArgoCD.
Select the dapr application card to open the dapr app details tree.
Locate the dapr secrets.
The secrets must be recreated. You can do this by deleting each secret.
Open the context menu of the secret and select Delete.
In the Delete resource confirmation dialog enter the name of the secret and select OK to confirm.
Repeat steps 4 and 5 for the remaining secrets.
In the dapr app details tree, locate the mutatingwebhookconfiguration.

Note:
You can recognize the mutatingwebhookconfiguration from the label MWC.
Open the context menu of the secret and select Delete. In the Delete resource confirmation dialog enter the name of the mutatingwebhookconfiguration and select OK to confirm.

Syncing the dapr secrects and the mutatingwebhookconfiguration

Some of the secrets are immediately recreated. This is indicated by a green check mark on the secret card.
If a secret is not recreated, you need to sync to recreate the secret.
Locate the secret you want to recreate and select Sync from the context menu.
In the pop-up panel, select SYNCHRONIZE.
Repeat steps 2 and 3 for all the secrets that you want to recreate.
In the dapr app details tree, locate the mutatingwebhookconfiguration.

Note:
You can recognize the mutatingwebhookconfiguration from the label MWC.
Open the context menu for the mutatingwebhookconfiguration and select Sync.
In the pop-up panel, select SYNCHRONIZE.

Restarting the deployment

After you deleted and synchronized the secrets and the mutatingwebhookconfiguration, you need to restart the deployment.

In the dapr app details tree, locate the dapr-sentry deploy card.
Open the context menu and select Restart.

A confirmation dialog is displayed.
Select OK to confirm the restart. The dapr-sentry deployment starts. When the deployment is finished, a green heart appears. Wait for the deployment to be finished.
In the dapr app details tree, locate the dapr-operator deploy card.
Open the context menu and select Restart.
In the confirmation dialog, select OK to confirm the restart. Wait for the deployment to be finished.
In the dapr app details tree, locate the dapr- sidecar-injector deploy card.
Open the context menu and select Restart.
In the confirmation dialog, select OK to confirm the restart. Wait for the deployment to be finished.

Important:

Restart the deployments in the described order and make sure a deployment is ready before starting the next deployment.

dapr-sentry
dapr-operator
dapr-sidecar-injector

You can now check that dapr is working correctly by looking at processmining, as described above. Now there should be 3 containers in the pod and the daprd container should be present in the LOGS.