Fix lazy auth with dataloaded value #4036
Conversation
| @@ -1122,4 +1122,64 @@ def nested2 | |||
| assert_equal({ "data" => { "nested2" => "nested2" } }, NestedDataloaderCallsSchema.execute("{ nested2 }")) | |||
| assert_equal({ "data" => { "nested" => "nested", "nested2" => "nested2" } }, NestedDataloaderCallsSchema.execute("{ nested nested2 }")) | |||
| end | |||
|
|
|||
| describe "with lazy authorization hooks" do | |||
There was a problem hiding this comment.
Caveat: I have fairly low context for this question so please feel free to ignore it.
Was the bug just with authorization methods returning lazy values? Or could other parts of the resolver chain like scope_items or field extensions (that use dataloader) also create similarly shaped issues.
Would it make sense to test various lazy/dataloader nestings of those features as well?
There was a problem hiding this comment.
IMO, this test is sufficient. The bug was at a lower level than any particular GraphQL feature -- instead, it was a bug about how dataloader and lazy values hand off control to one another.
Previously, the lazy resolution code was enqueuing itself as a single job in the dataloader. This didn't work if an already-enqueued job would require multiple passes to populate some key/value pairs in the response object. (The lazy resolution code uses response objects directly to find Lazys to resolve.)
So instead of queuing up a single job and assuming that any preceding jobs will populate the response objects, now, it calls dataloader.run to make sure that all preceding jobs have totally finished before using response objects.
Fixes #4021