@sefi18 Hi again,
I was able to successfully create a supergraph using the @extends directive. There is a problem that the directive is not removed at the end (which will need to be addressed but is possibly benign). However, I am unable to replicate your error.
At this point, it would be extremely helpful if you could share your subgraphs with me. Or at least just all and any root operations (subscription, query, mutation), also making sure ALL of those feature @extends.
Thanks,
David
Hi @DavidS,
I can reproduce it with the Netflix DGS federation example:
The example is working with Apollo gateway, although it does not even have @extends at the query types.
So I added the directive manually:
Shows:
type Query @extends{
shows(titleFilter: String): [Show]
}
type Show @key(fields: "id") {
id: ID
title: String
releaseYear: Int
}
Reviews:
type Show @key(fields: "id") @extends {
id: ID @external
reviews: [Review]
}
type Review {
starRating: Int
}
type Query @extends{
}
Hi there,
Could you please try removing the empty Query in Reviews, and then attempting the federation?
Does not work eitherâŚ
I added it for my tests, because otherwise DGS adds a query type without @extends to the SDL.
Hi again,
So you can confirm that your only two subgraphs are
Shows:
type Query @extends{
shows(titleFilter: String): [Show]
}
type Show @key(fields: "id") {
id: ID
title: String
releaseYear: Int
}
Reviews:
type Show @key(fields: "id") @extends {
id: ID @external
reviews: [Review]
}
type Review {
starRating: Int
}
Appearing exactly as above (updated with the changes applied/saved), and the supergraph is an attempted federation of these two subgraphs? And the error remains the same; i.e., âSupergraph schema validation failed: âthere can be only one query type in schemaââ?
Thanks for your patience and assistance on this.
David
Hi again,
Iâve done some digging, and the error youâre seeing is due to something like this occurring multiple times:
schema {
query: Query
}
The federation should be successful even without the @extends directive. The problem is that the query is somehow being declared multiple times. If your subgraphs appear exactly as you have posted, I am not sure how or why this is occurring.
David
Hey @DavidS,
we are slowly getting to the bottom of this. 
I think we have to distinguish between two schemas:
query sdl {
_service {
sdl
}
}
This SDL should be the source for the federation gateway.
The Netflix DGS framework (or probably the underlying graphql-java library) generates an entry
schema {
query: Query
}
into this SDL for every downstream service (even if this is not explicitly part of the âinputâ schema, see 1.).
The question would be: Is this behavior correct as specified? Would this be a point where Tyk would have to be a little more lenient and robust? Or is it a bug in the graphql-java library?
The Apollo Gateway by the way accepts these SDLs⌠
This is what the SDL string for âshowsâ looks like then, when queried as described:
schema {\n query: Query\n}\n\ntype Query {\n shows(titleFilter: String): [Show]\n}\n\ntype Show @key(fields : \"id\") {\n id: ID\n releaseYear: Int\n title: String\n}\n\nenum ErrorDetail {\n \"\"\"\n The deadline expired before the operation could complete.\n \n For operations that change the state of the system, this error\n may be returned even if the operation has completed successfully.\n For example, a successful response from a server could have been\n delayed long enough for the deadline to expire.\n \n HTTP Mapping: 504 Gateway Timeout\n Error Type: UNAVAILABLE\n \"\"\"\n DEADLINE_EXCEEDED\n \"\"\"\n The server detected that the client is exhibiting a behavior that\n might be generating excessive load.\n \n HTTP Mapping: 429 Too Many Requests or 420 Enhance Your Calm\n Error Type: UNAVAILABLE\n \"\"\"\n ENHANCE_YOUR_CALM\n \"\"\"\n The requested field is not found in the schema.\n \n This differs from `NOT_FOUND` in that `NOT_FOUND` should be used when a\n query is valid, but is unable to return a result (if, for example, a\n specific video id doesn't exist). `FIELD_NOT_FOUND` is intended to be\n returned by the server to signify that the requested field is not known to exist.\n This may be returned in lieu of failing the entire query.\n See also `PERMISSION_DENIED` for cases where the\n requested field is invalid only for the given user or class of users.\n \n HTTP Mapping: 404 Not Found\n Error Type: BAD_REQUEST\n \"\"\"\n FIELD_NOT_FOUND\n \"\"\"\n The client specified an invalid argument.\n \n Note that this differs from `FAILED_PRECONDITION`.\n `INVALID_ARGUMENT` indicates arguments that are problematic\n regardless of the state of the system (e.g., a malformed file name).\n \n HTTP Mapping: 400 Bad Request\n Error Type: BAD_REQUEST\n \"\"\"\n INVALID_ARGUMENT\n \"\"\"\n The provided cursor is not valid.\n \n The most common usage for this error is when a client is paginating\n through a list that uses stateful cursors. In that case, the provided\n cursor may be expired.\n \n HTTP Mapping: 404 Not Found\n Error Type: NOT_FOUND\n \"\"\"\n INVALID_CURSOR\n \"\"\"\n Unable to perform operation because a required resource is missing.\n \n Example: Client is attempting to refresh a list, but the specified\n list is expired. This requires an action by the client to get a new list.\n \n If the user is simply trying GET a resource that is not found,\n use the NOT_FOUND error type. FAILED_PRECONDITION.MISSING_RESOURCE\n is to be used particularly when the user is performing an operation\n that requires a particular resource to exist.\n \n HTTP Mapping: 400 Bad Request or 500 Internal Server Error\n Error Type: FAILED_PRECONDITION\n \"\"\"\n MISSING_RESOURCE\n \"\"\"\n Service Error.\n \n There is a problem with an upstream service.\n \n This may be returned if a gateway receives an unknown error from a service\n or if a service is unreachable.\n If a request times out which waiting on a response from a service,\n `DEADLINE_EXCEEDED` may be returned instead.\n If a service returns a more specific error Type, the specific error Type may\n be returned instead.\n \n HTTP Mapping: 502 Bad Gateway\n Error Type: UNAVAILABLE\n \"\"\"\n SERVICE_ERROR\n \"\"\"\n Request failed due to network errors.\n \n HTTP Mapping: 503 Unavailable\n Error Type: UNAVAILABLE\n \"\"\"\n TCP_FAILURE\n \"\"\"\n Request throttled based on server concurrency limits.\n \n HTTP Mapping: 503 Unavailable\n Error Type: UNAVAILABLE\n \"\"\"\n THROTTLED_CONCURRENCY\n \"\"\"\n Request throttled based on server CPU limits\n \n HTTP Mapping: 503 Unavailable.\n Error Type: UNAVAILABLE\n \"\"\"\n THROTTLED_CPU\n \"\"\"\n The operation is not implemented or is not currently supported/enabled.\n \n HTTP Mapping: 501 Not Implemented\n Error Type: BAD_REQUEST\n \"\"\"\n UNIMPLEMENTED\n \"\"\"\n Unknown error.\n \n This error should only be returned when no other error detail applies.\n If a client sees an unknown errorDetail, it will be interpreted as UNKNOWN.\n \n HTTP Mapping: 500 Internal Server Error\n \"\"\"\n UNKNOWN\n}\n\nenum ErrorType {\n \"\"\"\n Bad Request.\n \n There is a problem with the request.\n Retrying the same request is not likely to succeed.\n An example would be a query or argument that cannot be deserialized.\n \n HTTP Mapping: 400 Bad Request\n \"\"\"\n BAD_REQUEST\n \"\"\"\n The operation was rejected because the system is not in a state\n required for the operation's execution. For example, the directory\n to be deleted is non-empty, an rmdir operation is applied to\n a non-directory, etc.\n \n Service implementers can use the following guidelines to decide\n between `FAILED_PRECONDITION` and `UNAVAILABLE`:\n \n - Use `UNAVAILABLE` if the client can retry just the failing call.\n - Use `FAILED_PRECONDITION` if the client should not retry until\n the system state has been explicitly fixed. E.g., if an \"rmdir\"\n fails because the directory is non-empty, `FAILED_PRECONDITION`\n should be returned since the client should not retry unless\n the files are deleted from the directory.\n \n HTTP Mapping: 400 Bad Request or 500 Internal Server Error\n \"\"\"\n FAILED_PRECONDITION\n \"\"\"\n Internal error.\n \n An unexpected internal error was encountered. This means that some\n invariants expected by the underlying system have been broken.\n This error code is reserved for serious errors.\n \n HTTP Mapping: 500 Internal Server Error\n \"\"\"\n INTERNAL\n \"\"\"\n The requested entity was not found.\n \n This could apply to a resource that has never existed (e.g. bad resource id),\n or a resource that no longer exists (e.g. cache expired.)\n \n Note to server developers: if a request is denied for an entire class\n of users, such as gradual feature rollout or undocumented allowlist,\n `NOT_FOUND` may be used. If a request is denied for some users within\n a class of users, such as user-based access control, `PERMISSION_DENIED`\n must be used.\n \n HTTP Mapping: 404 Not Found\n \"\"\"\n NOT_FOUND\n \"\"\"\n The caller does not have permission to execute the specified\n operation.\n \n `PERMISSION_DENIED` must not be used for rejections\n caused by exhausting some resource or quota.\n `PERMISSION_DENIED` must not be used if the caller\n cannot be identified (use `UNAUTHENTICATED`\n instead for those errors).\n \n This error Type does not imply the\n request is valid or the requested entity exists or satisfies\n other pre-conditions.\n \n HTTP Mapping: 403 Forbidden\n \"\"\"\n PERMISSION_DENIED\n \"\"\"\n The request does not have valid authentication credentials.\n \n This is intended to be returned only for routes that require\n authentication.\n \n HTTP Mapping: 401 Unauthorized\n \"\"\"\n UNAUTHENTICATED\n \"\"\"\n Currently Unavailable.\n \n The service is currently unavailable. This is most likely a\n transient condition, which can be corrected by retrying with\n a backoff.\n \n HTTP Mapping: 503 Unavailable\n \"\"\"\n UNAVAILABLE\n \"\"\"\n Unknown error.\n \n For example, this error may be returned when\n an error code received from another address space belongs to\n an error space that is not known in this address space. Also\n errors raised by APIs that do not return enough error information\n may be converted to this error.\n \n If a client sees an unknown errorType, it will be interpreted as UNKNOWN.\n Unknown errors MUST NOT trigger any special behavior. These MAY be treated\n by an implementation as being equivalent to INTERNAL.\n \n When possible, a more specific error should be provided.\n \n HTTP Mapping: 520 Unknown Error\n \"\"\"\n UNKNOWN\n}\n
Hello @sefi18 I had a long discussion with @DavidS about this. I will take a look and try to reproduce the issue and see what we can do from there!
We believe that this could be a bug in the java library. However, this will also require some investigation to determine what and why itâs happening. I canât promise a timeline, but weâll try to keep you updated.
Hi @sefi18, I tried to replicate the problem with no luck so far. I set aside some time again this week. I will update once I have something.
Hi @sefi18, below are my findingsâŚ
The main issue is in the SDL returned. As you mentioned above the
schema {
query: Query
}
Is causing problems. I am not sure if this is a bug in our library or the Java one. This can easily be by passed. We can route the SDL requests through an API that transforms the result and remove that bit.
The other problem I noticed is that one of the graphsâ SDLs has a query with an empty body which is again causing a problem.
The extend vs @extends seem to work fine regardless.
My question is, how will this work with multiple subgraphs adding entry points to the Query type? Because the SDL does not add extend or @extends to the Query type.
I did some more research on this.
I believe that the schema part is something we should support. However the type Query with an empty body violates the GraphQL schema. Here is the reference. Specifically the first point
An Object type must define one or more fields.
We can try to resolve this with a transformation on the SDL API request. Let me know if you are interested I can wait for you on that.
I am wondering if we can build an SDL transformer for java-graphql because the routing and query building works fine. Its just the SDL format.
Hi @zaid
thank you for your research!
A workaround via SDL transformation could be interesting, but a more sustainable solution would be better. Otherwise the next one will stumble over the same problem again.
Either it is a bug in the Java libraries or it should be fixed in the Tyk gateway.
I also did some research on the Java side, here are my findings:
1. Schema definition in SDL
2. Empty Query type
The query root operation type must be provided and must be an Object type. (reference)
For the above reasons, I would rather see this as a fix in the Tyk Gateway. What do you think?
Thanks again for the support and have a nice weekend!
Sebastian
Hello @sefi18
I completely agree!
You have convinced me. I created a ticket for us to investigate further. This would be required to anyone who uses the graphql-java library, so we should at least have an official answer to whither we support it or not.
This also makes sense to me. Let me create a ticket for it as well.
Thank you for doing this research on your end, I really appreciate it.