search

absinthe-graphql / dataloader

DataLoader for Elixir
MIT License
485 stars 99 forks source link

Cryptic "bad bug" on patch update #165

Open coladarci opened 1 year ago

coladarci commented 1 year ago

Hey all - this is mostly to help others out in case they run into this (and I'm also super curious why but that's less important).

tl;dr is that we are now on v2 and have updated our application code to make this a non-issue but it was a super cryptic and I think interesting, bug..

When doing a routine update https://github.com/absinthe-graphql/dataloader/compare/v1.0.9...v1.0.11 we noticed a bunch of our has_many relationships being resolved with dataloader started to be empty.

In digging into this we noticed it was because we are using a view for our main model to filter out deleted records. i.e we have a data model like

parents and a view parents_non_deleted which is a select * from parents where deleted_at is nil - we then point our Parent schema at parents_non_deleted. (This pattern is one I consider an anti-pattern and what we removed to fix the bug)

But continuing on - if a Parent is deleted we still have a few flows where we allow you to return them. And in those cases you will want to ask gql for parent { children { name } }.

When resolving children for a parent who was deleted, children always comes back empty. We aren't doing anything special here; just field :children, non_null(list_of(non_null(:child))) resolve: dataloader(:dl_my_data_source)

Reverting to 1.0.9 makes them present. Bumping to 2 does NOT make the present. Removing our view and manually filtering out records with deleted_at non_nil DOES make them come back in all releases.

benwilson512 commented 1 year ago

Hey @coladarci I wonder if this is related to #144 which increased the number of scenarios where lateral joins are used?

I sort of follow the scenario you're outlining, but is there any chance you're able to show a reproducable example?