I just had a situation happen in a unique environment that has undergone juju series upgrades (1.25 -> 2.4.x -> 2.5-beta3), and trusty->xenial series upgrade and is now going through openstack charm upgrades. We had a relation-changed hook in the keystone charm firing during a leadership re-election where the identity-credentials-relation-changed hook was trying to perform leader-set functions as the unit was the elected-leader at time of the hook execution. Somehow, juju controller lost this state and no keystone units had leadership. I performed a resolved --no-retry to drop that action, but the next hook that fired also had state of being run in a is-leader=true context.
Checking juju status, no unit of keystone had leadership, and the leader-set commands were returning leadership-election cycling too quickly, try again later errors.
To resolve, I stopped the jujud-unit-keystone-X service and once juju controllers lost that agent, it then elected one of the other units leader and I was able to restart that unit.
It seems that the hook context kept leadership knowledge somehow, but the juju controllers did not agree that the unit was leader, but it didn't actually list any other unit as a leader, almost like it knew that this unit was stuck in a state of knowing it was leader, but not allowing it to continue functioning as leader until it could get to a leader-changed hook or agent lost state.
Do we have any logs of the actual hook execs going on during this time? They'd be really helpful in trying to track the logic and possible repro steps.