Activity

1. stvpwrs commented on Nov 14, 2023

   

   Steve Powers (stvpwrs)

   on Nov 14, 2023

   More actions

   Hey Andriy Berezhanskyy (@aberezh) I have encountered this issue too. For me, the issue was because I was running on Windows and I needed to add the following to my script:

   asyncio.set_event_loop_policy(asyncio.WindowsSelectorEventLoopPolicy())
   

   That fixed the issue for me.

   Good luck!
2. preslavnolimit commented on Nov 14, 2023

   

   preslavnolimit

   on Nov 14, 2023

   Last edited by preslavnolimit

   More actions

   I am having the same issue on Mac with Apple Silicon M2.

   I manage to duck tape it similar to the example, but the exact example gives that "Future is not in same loop" on the second call. So I basically did that

   try: 
       result = asyncio.run(graphclient.users.post(user_info))
       return result
   except RunTimeError as e
       if str(e) == "Event Loop is closed"
           loop = asyncio.get_new_loop() 
           asyncio.set_loop(loop)
           result = loop.run_until_complete(graphclient.users.post(user_info))
           asyncio.set_loop(None)
           loop.close()
           return result
   

   This works for handling the "Event loop is closed problem", but sometimes I get http error from httpx timeout not sure if I am making it or the graph api is responsible.

   The strange thing about my solution derived from the author of the issue #366 (comment)

   is that asyncio.run actually does the same thing, not any different and it should work only with asyncio.run if look into the source code of the function "run".
3. steph409 commented on Nov 15, 2023

   

   Stephanie Lanius (steph409)

   on Nov 15, 2023

   More actions

   I have the same problem running on Linux.
4. pclausen1 commented on Nov 28, 2023

   

   pclausen1

   on Nov 28, 2023

   More actions

   I had the same problem running in python 3.10 in Linux container. Was able to use similar workaround as others

   client = GraphServiceClient(credentials=credentials, scopes=scopes)
   loop = asyncio.get_event_loop()
   user1 = loop.run_until_complete(client.users.by_user_id(id1).get())
   user2 = loop.run_until_complete(client.users.by_user_id(id2).get())

   I see though that get_event_loop() is deprecated in python 3.12, so perhaps need to replace with something similar to Andriy Berezhanskyy (@aberezh) solution, but with get_running_loop() instead

   def get_loop():
       try:
           loop = asyncio.get_running_loop()
       except RuntimeError:
           loop = asyncio.new_event_loop()
           asyncio.set_event_loop(loop)
       return loop
   
   client = GraphServiceClient(credentials=credentials, scopes=scopes)
   loop = get_loop()
   user1 = loop.run_until_complete(client.users.by_user_id(id1).get())
   user2 = loop.run_until_complete(client.users.by_user_id(id2).get())```
5. advsysal commented on Dec 13, 2023

   

   advsysal

   on Dec 13, 2023

   More actions

   I have found a straightforward solution that seems to work across multiple hosting platforms (windows, databricks notebooks). It's similar to some of the above solutions, but a 1 liner...
   instead of:
   asyncio.run(my_graph_function())
   use:
   asyncio.get_event_loop().run_until_complete(my_graph_function())
6. erpola commented on Dec 26, 2023

   

   Eric Polanco (erpola)

   on Dec 26, 2023

   More actions

   def get_loop():
       try: 
           loop = asyncio.get_event_loop()
       except RuntimeError:
           loop = asyncio.new_event_loop()
           asyncio.set_event_loop(loop)
       return loop
   

   calling the asyncio.run as get_loop().run_until_complete() works greats for this issue. thank you Andriy Berezhanskyy (@aberezh)
7. Nintorac commented on Dec 31, 2023

   

   Nintorac

   on Dec 31, 2023

   Last edited by Nintorac

   More actions

   I get a similar issue in a DuckDB udf, my error looks like this

   duckdb.duckdb.InvalidInputException: Invalid Input Error: Python exception occurred while executing the UDF: RuntimeError: <asyncio.locks.Event object at 0x7f58eef84160 [unset]> is bound to a different event loop
   
   At:
     /opt/conda/envs/proj/lib/python3.10/asyncio/mixins.py(30): _get_loop
     /opt/conda/envs/proj/lib/python3.10/asyncio/locks.py(211): wait
   

   and @cireps workaround works for my situation too
8. sstoops commented on Feb 1, 2024

   

   Sean Stoops (sstoops)

   on Feb 1, 2024

   Last edited by sstoops

   More actions

   My team ran into this exact issue, though under slightly different circumstances. We need to use the Graph API within the context of an Async Django request. We found the exact same behavior: the first request would succeed and subsequent requests would throw the RuntimeError: Event loop is closed error.

   While a few folks here have proposed different workaround to deal with the event loop itself, I wanted figure out why the SDK was hanging on to references to event loops.

   Background

   Using Async Django as the example, since it is where I ran into this issue, if you're not running a pure async stack (eg. one of your middlewares is non-async), then Django will run each request in a new thread with a new event loop. The Django debug server will also exhibit the same thread-per-request behavior even if you are top-to-bottom async.

   This is similar to the behavior described in this issue: calling asyncio.run multiple times from a script. I believe this is also the same issue reported in #82.

   Cause

   So something, somewhere in the SDK is grabbing a reference to an event loop, and attempting to use that reference during a subsequent request.

   After much sleuthing, I found the pattern leading to this behavior:

   • Looking at the GraphServiceClient source, I found in its __init__ method that it constructs a GraphRequestAdapter
   • Digging into the GraphRequestAdapter, I found the following used as an argument to the __init__: client = GraphClientFactory.create_with_default_middleware(options=options). That line means that it will generate a default client factory at the time this module is imported, not when it is executed.
   • Let's keep digging.
   • Drilling into the GraphClientFactory.create_with_default_middleware method, we see the same pattern in the arg default: client: httpx.AsyncClient = KiotaClientFactory.get_default_client(). Again, that line is executed when the module is first imported, not when the function is called. That means all instances of GraphClientFactory will share the same client object that was created under whichever thread/event loop the module was imported in.

   To summarize all that, every GraphServiceClient you create is going to end up sharing the same underlying httpx.AsyncClient. That httpx.AsyncClient instance is constructed when you import the module, not when you actually run any code. This client is what (eventually) holds on to the reference to the event loop.

   Our workaround

   I managed to come up with a workaround that seems to be working so far. It has been tested both in a non-pure-async Django stack (meaning there's a sync middleware causing Django shuttle requests out to threads) and in the Django debug server.

   from typing import Optional
   
   from azure.identity.aio import ClientSecretCredential
   from kiota_authentication_azure.azure_identity_authentication_provider import (
       AzureIdentityAuthenticationProvider,
   )
   from kiota_http.kiota_client_factory import KiotaClientFactory
   from msgraph.graph_request_adapter import GraphRequestAdapter, options
   from msgraph.graph_service_client import GraphServiceClient
   from msgraph_core import GraphClientFactory
   
   
   def get_request_adapter(
       credentials: ClientSecretCredential, scopes: Optional[list[str]] = None
   ) -> GraphRequestAdapter:
       if scopes:
           auth_provider = AzureIdentityAuthenticationProvider(credentials=credentials, scopes=scopes)
       else:
           auth_provider = AzureIdentityAuthenticationProvider(credentials=credentials)
   
       return GraphRequestAdapter(
           auth_provider=auth_provider,
           client=GraphClientFactory.create_with_default_middleware(
               options=options, client=KiotaClientFactory.get_default_client()
           ),
       )
   
   def create_client() -> GraphServiceClient:
       return GraphServiceClient(
           request_adapter=get_request_adapter(
               credentials=..., scopes=['https://graph.microsoft.com/.default']
           )
       )

   What does this do?

   GraphServiceClient can accept either credentials and scope, resulting in it constructing an auth scope and request adapter for you, or it can just accept an existing request adapter.

   The get_request_adapter function essentially mimics the existing SDK code, but instead of constructing any clients at the global scope (during import), it constructs a new request adapter each time you construct a client.

   With this code, you could create a new client within the scope of your async code.

   For example:

   async def foo():
       # Client created within each run and with it's own event loop. Good.
       client = create_client()
       client.users.list()
   
   asyncio.run(foo())
   asyncio.run(foo())

   Note that the two calls to asyncio.run(...), and therefore two event loops, now succeeds.

   Addendum

   There are many other instances in the SDK where clients are constructed within the scope of a method's default args, meaning, at the global scope. My workaround was the bare minimum I needed to get around the closed event loop issue for my own use case. If you run into this error in other parts of the SDK, I suggest looking for this problematic pattern.

   👍React with 👍16Reacted by Sherd White, Dan, Kit Dallege, Chris Thompson, Niklas, Gaby Soria, Philip Woelfel, Jussi Hietanen, Grace Gettert, Yehor Zhornovyi and 6 more

   🎉React with 🎉3Reacted by gabn88, Andrew Li and Guillermo Simeon
9. Andrew Omondi (andrueastman)

   added

   bugSomething isn't workingSomething isn't working

   on Apr 3, 2024
10. shemogumbe commented on Apr 23, 2024

    

    Shem Ogumbe (shemogumbe)

    on Apr 23, 2024

    Contributor

    More actions

    Thanks for documenting this,
    While this works and solves for your use case, having multiple asyncio runs is considered an antipattern.

    Typically, we should have one asyncio.run(), as it sets up the event loop and starts the asynchronous execution.
    Besides being considered an antipattern, it can cause unexpected behaviour, note that an event loop manages asynchronous tasks within a single execution context.

    To execute within a single loop, use asyncio.gather()

    With your workaround, I would consider closing the issue and moving it to a discussion for reference by anyone who might face a similar issue
11. Shem Ogumbe (shemogumbe)

    self-assigned this

    on Apr 23, 2024
12. shemogumbe commented on Apr 23, 2024

    

    Shem Ogumbe (shemogumbe)

    on Apr 23, 2024

    Contributor

    More actions

    Moved to #683
13. Shem Ogumbe (shemogumbe)

    closed this as completedon Apr 23, 2024
14. sstoops commented on Apr 23, 2024

    

    Sean Stoops (sstoops)

    on Apr 23, 2024

    Last edited by sstoops

    More actions

    Shem Ogumbe (@shemogumbe) The multiple calls to asyncio.run() was to show that the code can be called multiple times without encountering the event loop issue. The issue my team encountered was using a framework where we don't have control over the event loop. Multiple asyncio.run() calls simply emulates this behavior. I will update my comment to clarify.

    👍React with 👍1Reacted by Evgeny Prigorodov
15. IamMrandrew commented on May 13, 2024

    

    Andrew Li (IamMrandrew)

    on May 13, 2024

    More actions

    My team ran into this exact issue, though under slightly different circumstances. We need to use the Graph API within the context of an Async Django request. We found the exact same behavior: the first request would succeed and subsequent requests would throw the RuntimeError: Event loop is closed error.

    While a few folks here have proposed different workaround to deal with the event loop itself, I wanted figure out why the SDK was hanging on to references to event loops.

    Background

    Using Async Django as the example, since it is where I ran into this issue, if you're not running a pure async stack (eg. one of your middlewares is non-async), then Django will run each request in a new thread with a new event loop. The Django debug server will also exhibit the same thread-per-request behavior even if you are top-to-bottom async.

    This is similar to the behavior described in this issue: calling asyncio.run multiple times from a script. I believe this is also the same issue reported in #82.

    Cause

    So something, somewhere in the SDK is grabbing a reference to an event loop, and attempting to use that reference during a subsequent request.

    After much sleuthing, I found the pattern leading to this behavior:

    • Looking at the GraphServiceClient source, I found in its __init__ method that it constructs a GraphRequestAdapter
    • Digging into the GraphRequestAdapter, I found the following used as an argument to the __init__: client = GraphClientFactory.create_with_default_middleware(options=options). That line means that it will generate a default client factory at the time this module is imported, not when it is executed.
    • Let's keep digging.
    • Drilling into the GraphClientFactory.create_with_default_middleware method, we see the same pattern in the arg default: client: httpx.AsyncClient = KiotaClientFactory.get_default_client(). Again, that line is executed when the module is first imported, not when the function is called. That means all instances of GraphClientFactory will share the same client object that was created under whichever thread/event loop the module was imported in.

    To summarize all that, every GraphServiceClient you create is going to end up sharing the same underlying httpx.AsyncClient. That httpx.AsyncClient instance is constructed when you import the module, not when you actually run any code. This client is what (eventually) holds on to the reference to the event loop.

    Our workaround

    I managed to come up with a workaround that seems to be working so far. It has been tested both in a non-pure-async Django stack (meaning there's a sync middleware causing Django shuttle requests out to threads) and in the Django debug server.

    from typing import Optional
    
    from azure.identity.aio import ClientSecretCredential
    from kiota_authentication_azure.azure_identity_authentication_provider import (
        AzureIdentityAuthenticationProvider,
    )
    from kiota_http.kiota_client_factory import KiotaClientFactory
    from msgraph.graph_request_adapter import GraphRequestAdapter, options
    from msgraph.graph_service_client import GraphServiceClient
    from msgraph_core import GraphClientFactory
    
    
    def get_request_adapter(
        credentials: ClientSecretCredential, scopes: Optional[list[str]] = None
    ) -> GraphRequestAdapter:
        if scopes:
            auth_provider = AzureIdentityAuthenticationProvider(credentials=credentials, scopes=scopes)
        else:
            auth_provider = AzureIdentityAuthenticationProvider(credentials=credentials)
    
        return GraphRequestAdapter(
            auth_provider=auth_provider,
            client=GraphClientFactory.create_with_default_middleware(
                options=options, client=KiotaClientFactory.get_default_client()
            ),
        )
    
    def create_client() -> GraphServiceClient:
        return GraphServiceClient(
            request_adapter=get_request_adapter(
                credentials=..., scopes=['https://graph.microsoft.com/.default']
            )
        )

    What does this do?

    GraphServiceClient can accept either credentials and scope, resulting in it constructing an auth scope and request adapter for you, or it can just accept an existing request adapter.

    The get_request_adapter function essentially mimics the existing SDK code, but instead of constructing any clients at the global scope (during import), it constructs a new request adapter each time you construct a client.

    With this code, you could create a new client within the scope of your async code.

    For example:

    async def foo():
        # Client created within each run and with it's own event loop. Good.
        client = create_client()
        client.users.list()
    
    asyncio.run(foo())
    asyncio.run(foo())

    Note that the two calls to asyncio.run(...), and therefore two event loops, now succeeds.

    Addendum

    There are many other instances in the SDK where clients are constructed within the scope of a method's default args, meaning, at the global scope. My workaround was the bare minimum I needed to get around the closed event loop issue for my own use case. If you run into this error in other parts of the SDK, I suggest looking for this problematic pattern.

    I used this workaround for my Flask application with async extra, together with creating a new client every time when accepting a request.

    It solves the issue where I was getting the RuntimeError: Event loop is closed error on my second request after the application starts.

    Not sure if it affect performance or as anti-pattern. But I couldn't find relevant examples on how should I implement it with this SDK. Let me know if there's update on this.

    🎉React with 🎉1Reacted by Sean Stoops
16. vschmidt commented on Aug 28, 2025

    

    Vinicio Schmidt (vschmidt)

    on Aug 28, 2025

    More actions

    My team ran into this exact issue, though under slightly different circumstances. We need to use the Graph API within the context of an Async Django request. We found the exact same behavior: the first request would succeed and subsequent requests would throw the RuntimeError: Event loop is closed error.

    While a few folks here have proposed different workaround to deal with the event loop itself, I wanted figure out why the SDK was hanging on to references to event loops.

    Background

    Using Async Django as the example, since it is where I ran into this issue, if you're not running a pure async stack (eg. one of your middlewares is non-async), then Django will run each request in a new thread with a new event loop. The Django debug server will also exhibit the same thread-per-request behavior even if you are top-to-bottom async.

    This is similar to the behavior described in this issue: calling asyncio.run multiple times from a script. I believe this is also the same issue reported in #82.

    Cause

    So something, somewhere in the SDK is grabbing a reference to an event loop, and attempting to use that reference during a subsequent request.

    After much sleuthing, I found the pattern leading to this behavior:

    • Looking at the GraphServiceClient source, I found in its __init__ method that it constructs a GraphRequestAdapter

    • Digging into the GraphRequestAdapter, I found the following used as an argument to the __init__: client = GraphClientFactory.create_with_default_middleware(options=options). That line means that it will generate a default client factory at the time this module is imported, not when it is executed.

    • Let's keep digging.

    • Drilling into the GraphClientFactory.create_with_default_middleware method, we see the same pattern in the arg default: client: httpx.AsyncClient = KiotaClientFactory.get_default_client(). Again, that line is executed when the module is first imported, not when the function is called. That means all instances of GraphClientFactory will share the same client object that was created under whichever thread/event loop the module was imported in.

    To summarize all that, every GraphServiceClient you create is going to end up sharing the same underlying httpx.AsyncClient. That httpx.AsyncClient instance is constructed when you import the module, not when you actually run any code. This client is what (eventually) holds on to the reference to the event loop.

    Our workaround

    I managed to come up with a workaround that seems to be working so far. It has been tested both in a non-pure-async Django stack (meaning there's a sync middleware causing Django shuttle requests out to threads) and in the Django debug server.

    from typing import Optional
    
    
    
    from azure.identity.aio import ClientSecretCredential
    
    from kiota_authentication_azure.azure_identity_authentication_provider import (
    
        AzureIdentityAuthenticationProvider,
    
    )
    
    from kiota_http.kiota_client_factory import KiotaClientFactory
    
    from msgraph.graph_request_adapter import GraphRequestAdapter, options
    
    from msgraph.graph_service_client import GraphServiceClient
    
    from msgraph_core import GraphClientFactory
    
    
    
    
    
    def get_request_adapter(
    
        credentials: ClientSecretCredential, scopes: Optional[list[str]] = None
    
    ) -> GraphRequestAdapter:
    
        if scopes:
    
            auth_provider = AzureIdentityAuthenticationProvider(credentials=credentials, scopes=scopes)
    
        else:
    
            auth_provider = AzureIdentityAuthenticationProvider(credentials=credentials)
    
    
    
        return GraphRequestAdapter(
    
            auth_provider=auth_provider,
    
            client=GraphClientFactory.create_with_default_middleware(
    
                options=options, client=KiotaClientFactory.get_default_client()
    
            ),
    
        )
    
    
    
    def create_client() -> GraphServiceClient:
    
        return GraphServiceClient(
    
            request_adapter=get_request_adapter(
    
                credentials=..., scopes=['https://graph.microsoft.com/.default']
    
            )
    
        )

    What does this do?

    GraphServiceClient can accept either credentials and scope, resulting in it constructing an auth scope and request adapter for you, or it can just accept an existing request adapter.

    The get_request_adapter function essentially mimics the existing SDK code, but instead of constructing any clients at the global scope (during import), it constructs a new request adapter each time you construct a client.

    With this code, you could create a new client within the scope of your async code.

    For example:

    async def foo():
    
        # Client created within each run and with it's own event loop. Good.
    
        client = create_client()
    
        client.users.list()
    
    
    
    asyncio.run(foo())
    
    asyncio.run(foo())

    Note that the two calls to asyncio.run(...), and therefore two event loops, now succeeds.

    Addendum

    There are many other instances in the SDK where clients are constructed within the scope of a method's default args, meaning, at the global scope. My workaround was the bare minimum I needed to get around the closed event loop issue for my own use case. If you run into this error in other parts of the SDK, I suggest looking for this problematic pattern.

    Thanks for this, this was the unique way to deal with loop breaks.
    I try several ways to deal with my coroutines, and this solve the problem.

    🎉React with 🎉1Reacted by Sean Stoops
17. Bain-OS commented on Aug 28, 2025

    

    Bain-OS

    on Aug 28, 2025

    More actions

    No description provided.
18. Christian Meier (cmeier76)

    added 3 commits that reference this issue on Mar 5, 2026

    fix(async): Added workaround for closed event loop

    ...

    7e41eb6

    fix(msgraph): Applied workaround for closed event loop

    ...

    45b9d05

    fix(msgraph): Applied workaround for closed event loop (#34)

    ...

    c2e5e40