Don't raise an error at close when it's expected

[EliseChouleur]

If session's close raises a SessionHandleInvalid error, that just means the session is already closed by other means.
So don't raise an error but just a warn message in this case.

[hug-dev]

Thanks for the PR!

means the session is already closed by other means

I am wondering if it's possible for the session to be closed by other means if the API has been used only using safe blocks? If not, it could be good to still have this message to show that something unexpected happened?

But maybe I am missing a flow where this could happen!

[wiktor-k]

If not, it could be good to still have this message to show that something unexpected happened?

Yep, it sounds as if there would be a double close in this scenario, which would be good to have in logs.

I wonder about the use case of other means of closing the session... 👀

[hug-dev]

I implemented something similar than what you propose here as part of #326 but checking explicitly is the session is already closed

[EliseChouleur]

Hi !

This happens to me when I remove the physical token before dropping the session. In this case, the session is automatically closed by the library in charge of this token.
To be correct, I think the session isn't really closed but the handle became invalid, that should be why I don't get the SessionClosed error as you're handling in the PR @hug-dev

[hug-dev]

Would my PR suffice then? That would allow you to explicitly call session.close() and filter on the error on your side?

[EliseChouleur]

I wanted to test the behaviour with your PR but the new implementation with the lifetime parameter on the session is a breaking change not compatible with my current implementation with the Pkcs11 context in a mutex and the session in a thread_local ref cell 😅