-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rover dev high cpu after composition failed #1906
Comments
Hack workaround... add a dummy subgraph to Was curious if schema-configured subgraph (instead of introspected) had the same issue # supergraph.yaml
federation_version: =2.7.0
subgraphs:
api:
schema:
subgraph_url: http://localhost:8080/graphql
dummy:
routing_url: http://localhost:9999/dummy
schema:
file: ./dummy.graphqls # dummy.graphqls
type Query {
dummy: String
} |
I have the same issue (on MacOS with rover 0.26.2). Composition failed and it's using loads of CPU.
It looks like these threads are spinning on crossbeam channels |
thanks for the report @benrea and the investigation, @nora-heydecker-axa! we're working on some related stuff right now and are keeping tabs on this issue to see if what we're doing resolves it |
Description
When running
rover dev
cpu usage spikes to ~100% following composition failed i.e. all subgraphs removed, and remains high even if subgraphs & composition are restored.Not specific to local development - also occurs with remote subgraph(s)
With multiple subgraphs, only occurs once all subgraphs removed
Doesn't occur if composition fails/no subgraphs were reachable on startup, though rover dev never retries in this scenario.
My desired setup is to run rover in docker for better local DX, which works but suffers the same issue.
Tested with rover 0.20.0, 0.21.0, 0.22.0, 0.23.0
Steps to reproduce
Example repo to reproduce with a single subgraph: https://github.com/benrea/rover-example
This mimics our setup using go + gqlgen + rover dev for local development against a federated graph.
Expected result
Cpu usage expected to spike during introspection(?) or genuine usage e.g. handling requests.
Actual result
Cpu usage spikes to ~100% and remains high, even after subgraphs/composition restored and operational.
Restarting rover / new process returns to normal.
Environment
The text was updated successfully, but these errors were encountered: