AlexCLeduc

Sorry about that, I was probably blindly chasing coverage 😄 I've added a new failing test case, you can see it fail with the `already-imported` warning in CI https://github.com/nedbat/coveragepy/runs/1851303652#step:7:108

Yes, we are using the promise package used by Core-2 and the dataloader class included with graphene 2.

Thanks for the advice, I'll look into middleware and `execution_context_class`. I've also followed up with graphene to see if they can re-add support for promises. You can close this issue...

@superlevure I'm still on graphene 2 and promise-based dataloaders, but the async dataloaders definitely work. The docs should ideally cover this, I can't think of a scenario where I'd use...

@superlevure, after playing around a bit with v3, getting async resolvers/dataloaders working correctly is quite easy when calling the schema directly (e.g. `schema.execute_async`) but there's more work involved in getting...

Thanks @jkimbo! Will this work in a nested context, e.g. dataloaders that compose one another, or a resolver that calls multiple dataloaders? It's not obvious to me how to chain...

@jkimbo Promises were chainable using the `.then(handler)` api. Are your future objects also chainable? If a resolver requires 2 dataloader calls, e.g. a grandparent field that calls a parent_loader twice,...

@jkimbo thanks for adding chaining! I tried to use it but I couldn't find an analog to `Promise.all` or `Dataloader.load_many` Thanks @ericls, your execution-context class was a drop in replacement...

@ericls yes I'm in that Ottawa haha. Glad to hear fellowapp is still using promises, makes me feel less crazy 😄 If anyone is interested in the generator syntactic sugar...

When I opened this issue, I was unaware the execution context was capable of adding promise support. I'm happy enough with @ericls's solution, we can close this