If, during removal of a unit using layer:tls-client and interface:tls-certificate, if layer:tls-client's store_server handler gets queued to run before interface:tls-certificate's TlsRequires.joined() method, it can result in errors during teardown under certain circumstances.
This can trigger the following failure:
File "/var/lib/juju/agents/unit-kubernetes-worker-26/charm/reactive/tls_client.py", line 51, in store_server
server_cert = server_cert + '\n' + chain
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
I have a few units which have hit this issue, which I was attempting to remove from the model when this occurred. They're related to vault, and were formerly related to 3 units, but only one unit remains related. This unit does not have the <unit>.server.cert nor <unit>.server.key values for the unit in question, nor are there any <unit>.processed_requests fields present in the relation either for that unit, and thus TlsRequires.get_server_cert() will return (None, None).
This wouldn't be a problem if layer:tls-client's store_server handler wasn't called. And it shouldn't be called... except that it fires on certificates.server.cert.available, which should be cleared when TlsRequires.joined() is called, except that it won't be called until after store_server is.
Thus, store_server is called, thinking it has a cert to store, when in fact it does not. It pulls get_server_cert, gets a bunch of nothing back, and things blow up as described in the above traceback.