Closed aandrieu closed 1 week ago
Hi! Sorry for the trouble and thanks for the detailed report. It sounds like I overlooked a compatibility issue somewhere... I'll take a look and follow up here.
I tried to replicate this issue locally, but I couldn't. The best thing to help debug would be a backtrace of the Ruby process while it's hung -- it would tell us what the server is doing that's taking so long (or stuck in a loop). You could do this at least two ways:
rbspy snapshot --pid=...
and share the result from that: https://rbspy.github.io/using-rbspy/snapshot.htmlEither of those would be really helpful. A couple other debugging ideas:
sync
that causes the server to hang? Does query execution work normally? What about MySchema.to_definition
, does that print the server properly? I wonder if something about Schema::Visibility
isn't handling your schema properly. If those don't work either, then if you could share the .to_definition
output of your schema, that would also be a great help in debugging. Feel free to email it to me instead of posting it here if you prefer. sync
hangs, the .to_definition
print-out of your schema might make me able to replicate the problem locally.Let me know what you find and we can keep looking into it! Thanks.
π Just checking in again about this! I'd love to track down this bug and release a fix. If you don't have time to investigate on your side, I might be able to find it with just a .to_definition
print-out of your schema, if you don't mind emailing me one.
Hello, sorry for the late answer, I will have more time this week.
Regarding the process:
I tried the first point but the server waits for a 'graceful' shutdown when I kill it and seems to never ends. Only force killing it worked but it logged nothing.
So I tried the second point with rbspy
and it works perfectly.
It seems there is a "loop" on graphql/language/static_visitor.rb:62
that is working just it is very slow.
We have 730+ operations.
On initial sync (starting from clean db):
On delta sync (6 updates including 1 on an operation with a visible?):
On usage: both seems to work fine.
So it just seems that the sync is slow with Visibility and it is not hanging.
We use lot a fragment and based on some investigations it seems that fragments are processed each time they are embedded. Not sure it is expected or should be the case.
I will see with our legal team if we can share the schema with you. I will continue to investigate on my side.
Here are additional infos.
It seems some part of base visitor are long vs the static visitior. Some of operations take more 15s for a single operation (involving 50+ fields ; 5/10 fragements)
With warden base visitor seems faster. For instance:
on_field (base visitor): 4.3999869376420975e-05s
on_field: 2.2999942302703857e-05s
This is so helpful -- thank you for sharing so much.
I don't think I need the schema print-out. My first guess was that some part of Schema::Visibility
's type definition discovery code was entering an infinite loop. But it sounds like that was wrong!
I'll dig into these examples and see what I can find. I bet there's a codepath in Schema::Visibility
that needs to be optimized. (#5154 was a similar issue.)
I think the problem is here:
each_field - ~/.rbenv/versions/3.3.6/lib/ruby/gems/3.3.0/gems/graphql-pro-1.29.2/lib/graphql/pro/operation_store/index_visitor.rb:112
possible_types - ~/.rbenv/versions/3.3.6/lib/ruby/gems/3.3.0/gems/graphql-2.4.2/lib/graphql/schema.rb:64
That codepath creates a new Visibility::Profile
each time, which re-traverses the schema. I'm going to improve the implementation in GraphQL-Ruby and update that call in GraphQL-Pro to use a cached-by-default version. (I just double-checked -- the other calls in graphql-pro are already updated.)
Top thanks. When you have something ready do not hesitate to ping me if you want me to test your branch against our schema π
Great -- almost there! Thanks again for bringing this issue to my attention.
π I just released GraphQL-Pro v1.29.3. Could you try that new version along with the improve-visibility-possible-types
branch (#5161)? You can bundle that branch like this:
gem "graphql", github: "rmosolgo/graphql-ruby", ref: "improve-visibility-possible-types"
Let me know how it goes for you! I'm planning to merge and release that branch on Monday.
Hello!
I tested the new version with the new schema visibility against our schema: everything worked fine π Same performances as before!
Many thanks for this fast response π
Glad to hear it!
Describe the bug
Hello,
We are using GraphQL Pro with OperationStore. We are also using visible? feature. It used to work fine but when we tried to update to the new visibility system the sync operation (graphql-ruby-client sync) stopped to work.
When we add nothing on our schema: sync works but we have a warning on rails. When we add only
use GraphQL::Schema::Warden
: sync works and we have no warning. When we add onlyuse GraphQL::Schema::Visibility
: sync hangs.Versions
graphql
version: 2.4.2graphql-pro
version: 1.29.2rails
(or other framework): 7.2.2graphql-ruby-client
version: 1.14.1Steps to reproduce
Hard to find exact steps to reproduce as it hangs in the middle of the process without further infos.
The hang seems to happen after this sql query:
We tried to add
migration_errors: true
but since it hangs nothing was ever returned :/Tell me if can provide any other informations that may help you π
Expected behavior
It should still work as before.
Actual behavior
What specifically went wrong? Process hangs and never stop.
Thank you