Build a Dataloader on Async gem primitives

[rmosolgo]

This is another attempt to get Dataloader to "Just Work" when it comes to running Source#fetch in the background.

This approach uses the async gem to handle backgrounding, using Async do ... end.

TODO:

• Sadly CI doesn't seem to like this. But It passes locally....
• Test: during GraphQL execution, does it run resolvers in parallel? (It might, since it uses Async { ... }.wait, but I don't have a test for it at the moment.
  • This was already covered in the existing tests
• Try a Ruby on Rails example app and make sure this will deliver as promised with ActiveRecord, Redis, and HTTP calls inside a Source.
  • Demo: https://github.com/rmosolgo/rails-graphql-async-demo
• Update the documents to recommend this implementation (remove references to other schedulers)

[trevorturk]

This is a bit in the weeds for me to truly review, but I gave things a read through and it looks good! I'm happy you've been able to make some progress here, and excited for the Async-ified Dataloader!

I see your todos in the PR description, and figured I'd share a bit of code I'm using in a Rails app running Falcon/Async and doing a lot of Async::HTTP work: https://gist.github.com/trevorturk/f8baeaf8a954bc3764d70652db1692fa -- one bit is around testing that things are running in parallel and the other is a fix for integration tests.

I'll keep an eye on this PR and report back if I have anything useful to share. Feel free to ping me if you have any questions I might be able to help with.

I'll also @ioquatix just in case he has the time/interest to put his eyes on this.

[rmosolgo]

I tried it in Rails and it worked like a charm! Net::HTTP and ActiveRecord ran in parallel without a problem. Demo: https://github.com/rmosolgo/rails-graphql-async-demo

[ioquatix]

You can visualise what is going on using the async-debug gem which is one line to drop into a test application (usually).

[rmosolgo]

I think I'm all set, application-wise. It's just CI -- it runs for hours but gets nowhere: https://github.com/rmosolgo/graphql-ruby/actions/runs/7196641771/job/19601940761

Actually, the Rails build (sometimes?) gets somewhere, but not too far: https://github.com/rmosolgo/graphql-ruby/actions/runs/7196641771/job/19601942904

I'm going to dig in and straighten it out tomorrow.

[ioquatix]

It’s not uncommon for CI to expose race conditions because scheduling is so much slower and thus unpredictable. I would suggest looking at scheduling operations.

[ioquatix]

I should add, tests that depend on sleep actually sleeping the desired amount of time, and sleep N finishing faster than sleep N+M may break. It's extremely tricky to write those sorts of tests on the CI as the actual vCPU seems incredibly unpredictable (and overloaded).

[rmosolgo]

🎉

It was scheduling code.

Previously I was relying on loops going round and round to eventually let everything resolve. But I had a test to make sure that the dataloader loop didn't exceed 1000 iterations. It was -- in fact, it was neverending -- so the test suite never finished.

I added an Async::Condition instead, so that Tasks which are waiting for some other data can wait on that condition, then when a dataloader loop is finished, it notifies the condition so that those tasks can start again.

@ioquatix, this is hot stuff! Thanks for this great library. I look forward to learning more, for example, applying semaphores to the internal list of dataloader jobs if the need arises (it hasn't yet...).

Edit: I got ahead of myself ... still a few commented-out tests to fix...

[rmosolgo]

Amazing. @ioquatix and @trevorturk, thanks again for your help along the way on this!

[ioquatix]

Nice work team!