Comment 6 for bug 1849323

The problem I see with the "last_token" logic present in charm-helpers is that, given that the loop always starts at vault/0, a leadership transition vault/0 => vault/1 => vault/2 will cause the code to always raise an exception, as the comparison will always be successful:

token (vault/0's) != last_token (vault/1's)

So the solutions are:

1) clear the data from old leaders(currently proposed): this works but has a timing issues, and then it will need juju resolved --no-retry to fix

2) have the leader propagate the new tokens to other vault units before setting relation data. This needs to be carefully implemented to not cause a timing issue. Even if propagated to other vault units, if vault/2 is the first to set the relation data while vault/0 still has stale data, it will cause errors.

the "last_token" logic can be also implemented in the interface to help mitigate the timing issue.