You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Investigate whether the async credentials should be closed by this library or by the caller #365
[Their documentation](https://learn.microsoft.com/en-us/python/api/azure-core/azure.core.credentials_async.asynctokencredential?view=azure-python) is terrible but I'm wondering what close does and whether we need to call it after each authentication request or when we don't need the credential object anymore? (wondering whether we'll have the same issue as the http package where it stops working after the first request)
sure, it might be a problem in some scenarios (singleton instances of credentials etc...) but we'll wait for customers to report something before spending mort time on this first.
Hello, I would like to ask to reopen this issue, as it seems to manifest e.g. in microsoftgraph/msgraph-sdk-python#505 , preventing long living instances of msgraph.GraphServiceClient from refreshing access tokens using an async Credential once they expire after an hour.
My suggestion would be to leave closing the credential entirely up to the user. For them it would then be easy to control the lifecycle of their credential instance by using it as context manager.
Closing the credential inside the library means that there is no way for the user to keep client instances alive for longer than one token lifetime, or to reuse the same credential to instantiate multiple clients.
At least in the case of using azure.identity.aio credentials, it also makes the application crash with a very obscure exception (AttributeError: 'NoneType' object has no attribute '__aenter__') caused by the credential not expecting to be accessed after getting closed, which can not easily be caught and handled in user code. However, handling this status more robustly would need to be a change in that library instead of here, just adding it for context.
Reacted by Christiaan-Mathu, Ben Brunyee, GeorgePals, Daniel Niccoli, Adam Law and savvasp-123
I have the same issue with GraphServiceClient and would like to know how I should be using it.
I am currently using it as a singleton and after the token expires then I get the following error:
venv/lib/python3.11/site-packages/azure/core/pipeline/transport/_aiohttp.py", line 255, in send
result = await self.session.request( # type: ignore
^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'request'
What other approach should I be using if this is not correct?
Christiaan-Mathu My current workaround is to prevent the credential from getting closed by the GraphServiceClient using a custom credential implementation.
I basically derive a custom class from the async credential class I want to use (here azure.identity.aio.DefaultAzureCredential) and override its async def close(self) method to do nothing.
Instead I add another custom method to the derived credential class, which calls the original super-class close method, so that I can still actually close the underlying credential from my own application code at the right time, just before terminating.
This seems to work fine, I had no issues with this approach so far.
Activity
sebastienlevert commentedon Feb 1, 2024
Vincent Biret (@baywet) is this closed?
baywet commentedon Feb 1, 2024
sure, it might be a problem in some scenarios (singleton instances of credentials etc...) but we'll wait for customers to report something before spending mort time on this first.
dico-harigkev commentedon Feb 14, 2024
Hello, I would like to ask to reopen this issue, as it seems to manifest e.g. in microsoftgraph/msgraph-sdk-python#505 , preventing long living instances of
msgraph.GraphServiceClientfrom refreshing access tokens using an async Credential once they expire after an hour.My suggestion would be to leave closing the credential entirely up to the user. For them it would then be easy to control the lifecycle of their credential instance by using it as context manager.
Closing the credential inside the library means that there is no way for the user to keep client instances alive for longer than one token lifetime, or to reuse the same credential to instantiate multiple clients.
At least in the case of using
azure.identity.aiocredentials, it also makes the application crash with a very obscure exception (AttributeError: 'NoneType' object has no attribute '__aenter__') caused by the credential not expecting to be accessed after getting closed, which can not easily be caught and handled in user code. However, handling this status more robustly would need to be a change in that library instead of here, just adding it for context.Christiaan-Mathu commentedon Feb 28, 2024
Hi Vincent Biret (@baywet), hope you are well,
I have the same issue with
GraphServiceClientand would like to know how I should be using it.I am currently using it as a singleton and after the token expires then I get the following error:
What other approach should I be using if this is not correct?
baywet commentedon Feb 28, 2024
Samwel K. (@samwelkanda) can you follow up on this one when you have some time please?
dico-harigkev commentedon Feb 29, 2024
Christiaan-Mathu My current workaround is to prevent the credential from getting closed by the GraphServiceClient using a custom credential implementation.
I basically derive a custom class from the async credential class I want to use (here
azure.identity.aio.DefaultAzureCredential) and override itsasync def close(self)method to do nothing.Instead I add another custom method to the derived credential class, which calls the original super-class close method, so that I can still actually close the underlying credential from my own application code at the right time, just before terminating.
This seems to work fine, I had no issues with this approach so far.