Firstly, yes I have read this https://www.liquibase.com/blog/using-liquibase-in-kubernetes and I also read many SO threads where people are answering "I solved the issue by using init-container"

I understand that for most people this might have fixed the issue because the reason their pods were going down was because the migration was taking too long and k8s probes killed the pods.

But what about when a new deployment is applied and the previous deployment was stuck a failed state (k8s trying again and again to launches the pods without success) ? When this new deployment is applied it will simply whip / replace all the failing pods and if this happens while Liquibase aquired the lock the pods (and its init containers) are killed and the DB will be left in a locked state requiring manual intervention.

Unless I missed something with k8s's init-container, using them doesn't really solve the issue described above right?

Is that the only solution currently available? What other solution could be used to avoid manual intervention ?

My first thought was to add some kind of custom code (either directly in the app before the Liquibase migration happens) or in init-container that would run before liquibase init-container runs to automatically unlock the DB if for example the lock is, let's say, 5 minutes old. Would that be acceptable or will it cause other issues i'm not thinking about ?