There is no current event loop in thread 'Thread-2 (process_request_thread)'.

[gwennlbh]

• What is the current behavior?

A simple query fails with a cryptic, seemingly asyncIO-related error:

{
  "errors": [
    {
      "message": "There is no current event loop in thread 'Thread-2 (process_request_thread)'.",
      "locations": [
        {
          "line": 34,
          "column": 3
        }
      ],
      "path": [
        "tests"
      ]
    }
  ],
  "data": {
    "tests": null
  }
}

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via

Link to reproduction repository: https://github.com/ewen-lbh/bug-report-django-graphene

Steps to reproduce:

1. git clone https://github.com/ewen-lbh/bug-report-django-graphene

2. cd bug-report-django-graphene

3. poetry install (or pip install -r requirements.txt )

4. cd repro

5. poetry run python manage.py migrate && poetry run python manage.py runserver

6. Navigate to 127.0.0.1:8000/graphql

7. Try executing the following query:

    {
    	tests {
    		testing
    	}
    }
   

• What is the expected behavior?

The query executes and returns its result

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • Version: graphene-django 3.0.0, django 4.1.5, python 3.10.9
  • Platform: Manjaro Linux 5.19.17-2-MANJARO

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow)

[bryantjamestech]

I'm seeing a similar issue when attempting to update. Any thoughts?

[mbrochh]

Same here. What I know so far is that the endpoing does work in principal, but fails only for certain objects. In my case, my endpoint should return several fields, one of them being product. Via ipdb I can see that the product was successfully queried and returned by my resolver, but it seems that graphene fails to properly serialize it. I stumble upon this while making test fixtures with mixer, so I'm dealing with a product that might have certain fields or values set to funky values, so that might be the reason why graphene seems to crash. So my guess right now would be that graphene crashes when it tries to serialize an object and then swallows the real error message.

[bryantjamestech]

Interesting... is it possible that maybe Graphene's expecting a value where there's none? EG something is None and v3 of Graphene-Django is expecting it not to be?

[bryantjamestech]

So it definitely is error handling being squelched. I also made a slight discovery. For Graphene-Django v2, I had a resolve function declared such as:

def resolve_nodes(root, info, kinds=[], root_path="/", language_code=ENGLISH, asset_kinds=None):

The value kinds was not defined by my query, but rather than passing no value for kinds the function is being passed None for kinds. So later on in my code there was an error because kinds was None when my code expected it to be a list by that point.

So not sure how to fix it such that the errors aren't being squelched, but that might at least give you a point to start looking.

[katomaso]

I had similar issue - it is caused by the debugging middleware that is using promises. If you have an error in your code (an error is thrown), then the debugging middleware kicks in but unfortunately eats up the original exception and fails on its own exception - because it is trying to access eventloop outside of the main thread.

Quick fix is to disable debugging middleware in your settings

# settings.py
GRAPHENE = {
    "MIDDLEWARE": (), # empty = force disable debugging middleware
    # ...
}

[TrialAndErrror]

Not sure if this is helpful for fixing the issue, but my quick fix when I've run into a "There is no current event loop in thread" type of error is to place a breakpoint in line 557 of site-packages/graphql/execution/execute.py and take a look at the result variable that is returned on line 521 from resolve_fn(source, info, **args).

Usually, result.result will show the actual underlying issue, and line 557 is the Except clause where it notices an error is raised but then has trouble returning the actual error.

[jaw9c]

Fixed by #1388. Confirmed by checking out example repo given, changing requirements.txt to the latest main and now reports the real error - @ewen-lbh can you confirm this?