-
Notifications
You must be signed in to change notification settings - Fork 92
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-286 Removing routing_url
gives correct error message
#2360
base: main
Are you sure you want to change the base?
Conversation
✅ Docs preview has no changesThe preview was not built because there were no changes. Build ID: f74d9e135f1afc5fe8d93c81 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a few comments to explain the more obscure parts
3145bae
to
547d269
Compare
8bb1f76
to
941370d
Compare
There seems to have been a thought that a subgraph should be considered added and removed if the `routing_url` changes. That is not a good idea and is now reverted.
In the past we considered a FullyResolvedSupergraphConfig to be forced to have a routing_url for each subgraph. While this is technically a reasonable assumption, from the POV of the LSP it's actually better to enable it to be an Option<String> instead. This means we can more accurately funnel errors from the `supergraph` binary rather than having to do a lot of error handling ourselves.
Now that we've allowed `routing_url` to be an Option, we can address the crux of the issue by updating a routing_url midstream.
941370d
to
9b2d53f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that at some point I thought that the pair of name and routing_url should uniquely identify a subgraph but that's nonsense and changing this doesn't break anything so I'm planning on reverting this and leaving it.
As per title, due to some particularly inconvenient handling of federation resolution subgraphs losing a routing_url while the LSP was running, or not having one to start with were causing us many problems. This is now resolved and I've run over the test suite we have and all tests are passing (with the exception of the
--profile
ones, which are a known issue).Some comments are added throughout to explain the decisions taken.