Shen Li

> https://github.com/jkimbo/graphql-sync-dataloaders That's good to hear! Do you know if the integrated solution will be based on something like https://github.com/jkimbo/graphql-sync-dataloaders/blob/main/graphql_sync_dataloaders/sync_future.py or is it going to be based on `asyncio.Future` or...

Just to make sure I understand where this is going, we are going to have our own Promise/Future-like class that is thenable and require all all resolvers/data-loaders to return an...

I'll submit a PR shortly. Also, is it documented anywhere why there's a restriction on the length of the names? Thank you!

@adamhooper If I'm not mistaken, loops are coupled to their threads. And `@sync_to_async` uses threadpool, where new loops are created. These loops cannot use connections established using in the loop...

Hi @carltongibson and @jpic, Sorry for the delay and thanks for the review and suggestions. I do plan to finish this PR by the end of tomorrow (eastern time)

> This needs to be rebased after #1792 Thanks for the reminder, I've rebased the changes on top of the latest main. I've also noticed that the current error message...

Does flushing redis after each run help?

The motivation of this is that I've found some torrents may have additional fields names, but they are still "usable" torrents. Changing from `to_existing_atom` to `to_atom` is actually bad. Dynamically...

Thanks @jkimbo for graphql-sync-dataloader. We were having the same issue and decided to translate the default executecontext to be promise aware and promise based. I started translating it as a...

> Glad you find it useful! That was basically a re-write of execution context, I'm glad graphql-core provides an API to override it. By the way, are you in Ottawa...