OpenBao remains sealed after cluster restart in common-components v2.3.2

Hello,

While working with common-components v2.3.2, I noticed that the OpenBao pod remains sealed after restarting the Kubernetes cluster.

Currently, the init-bao job initializes and unseals the instance correctly during the first deployment. However, when the cluster is restarted, OpenBao starts in a sealed state. This causes the readiness probe to fail (Unhealthy) and dependent services are unable to access secrets until the unseal process is done manually.

In my case, I was able to recover the system by manually unsealing the instance using the keys stored in secrets-unseal-keys.
That worked fine, but it made me wonder whether the unseal process is supposed to happen automatically after a restart, or if this manual step is the intended behavior.

Additionally, when trying to re-run init-bao via Argo CD deleting and sync, the job fails due to immutability:

Job.batch "init-bao" is invalid: spec.template: Invalid value: core.PodTemplateSpec{...}: field is immutable

So it seems init-bao does not execute again after the first run, which prevents any automatic re-unseal process.

Could you please confirm whether this is the expected behavior for OpenBao in common-components v2.3.2?
And if not, would it make sense for the unseal to be handled automatically after a restart (for example, via the existing init-bao job or another mechanism)?

Thank you in advance.