-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Poor interaction with threads (python 2.7) #43
Comments
I tested this with 2.7.15 and 3.7 - here are my query results: 2.7.15: 3.7: Are you seeing something different, @melancholy ? |
Yes. With concurrent requests I would frequently see errors in the logs. This only occurs when threading is on and requests are concurrent, so a single screenshot of a result won't reflect a proper step for reproduction. I also ended up tracking this down and working around it. It turns out the promise library isn't thread safe. I mentioned it in an issue for the promise library and described my workarounds. here's the issue: syrusakbary/promise#57 |
Any news on how to access context in resolvers with the ThreadExecutor ? |
the interaction between this library, graphql-core, and promise appears to allow execution to hop threads especially (only?) when using a middleware and nested resolvers. this is inconsistent with flasks threading model and the ability to access the request/g thread locals
with the attached (very contrived) example, when submitting the query with concurrent requests the requests frequently fail because the key created in get_context doesn't exist on the threadlocal flask.g object in the resolvers. This happens when a thread accesses the promise.async_instance which isn't thread local, and resolves a promise that was created on a different thread.
query.txt
The text was updated successfully, but these errors were encountered: