Robert Mosolgo

Wow! That's so strange. Thanks for the detailed writeup. My first idea is, maybe some types are being hidden from the client, so the field is being hidden. Do you...

Ok, thanks so much for sharing all these details. `AlwaysVisible` is certainly the most dubious of all the plugins -- I'm going to dig in there and see if I...

One more clarifying question: when a node returns an error response, does it keep returning error responses after that? Is it "stuck" in that state, or does it go back...

Thanks for sharing those. Unfortunately, I don't see any clues there at all 😖 As a matter of simplifying and ruling out some possibilities, could you deploy without AlwaysVisible and/or...

> use `.except` instead of `.except!` Yes, I'd agree that's the best way to go forward. It's nice to make sense of what was going on! Thanks for sharing all...

Hey, thanks for reporting this. Did you find this documented somewhere? I didn't find it in the documentation and I don't see it addressed in the relevant spec (https://github.com/rmosolgo/graphql-ruby/blob/master/spec/graphql/authorization_spec.rb), so...

Great point -- thanks for the detailed writeup! I think my previous change would have "fixed" this for any fields coming _after_ `def resolve` -- but the problem holds when...

I'd _expect_ it to work for those sub-fields, thanks to: https://github.com/rmosolgo/graphql-ruby/blob/58b5a3c0ee7b45737e1dd83bb4ff985bf9299f7e/lib/graphql/execution/interpreter/runtime.rb#L225-L229 I wrote up a little replication script which demonstrates the issue you described above (if you uncomment the last...

Oh, I see... yes, I'd certainly believe that. The runtime clears the dataloader cache before and after resolving each mutation, but `loads:` and `def self.authorized?` are part of resolution, from...

This could result in some unexpected runtime changes so I'm going to put it in a minor version release instead of a patch version.