@link appears to fail on "extend schema"
thiscompsciguy opened this issue · comments
The documentation suggests adding the @link directive using extend schema
extend schema
@link(url: "https://specs.apollo.dev/federation/v2.0",
import: ["@key", "@shareable"])
What we discovered when upgrading to version 2.1, this no longer works. We were able to get this to work when not using extend
schema
@link(url: "https://specs.apollo.dev/federation/v2.0",
import: ["@key", "@shareable"])
Both above work with version 2.0.8
From the docs:
You can apply this directive to your existing schema declaration if you have one, or to a new extend schema declaration (as shown above).
It should work with both. Sounds like a bug. Thanks for reporting!.
@thiscompsciguy do you mind providing a sample that reproduces the issue? Our test cases seem to be working -> e.g. https://github.com/apollographql/federation-jvm/blob/master/graphql-java-support/src/test/resources/schemas/composeDirective.graphql
An example of what our existing graph looks like. I think what's different here is we have both extend schema and schema. The work around has been to combine these. I believe the custom @tag directive is a red herring.
extend schema
@link(url: "https://specs.apollo.dev/federation/v2.0",
import: ["@key", "@inaccessible", "@override"])
"""
Custom tag directive we re-write during our deployment pipeline to be standard
tagging before composition. This adds SCHEMA to the possible locations.
"""
directive @tag(
name: String!
) repeatable on
FIELD_DEFINITION
| OBJECT
| INTERFACE
| UNION
| ARGUMENT_DEFINITION
| SCALAR
| ENUM
| ENUM_VALUE
| INPUT_OBJECT
| INPUT_FIELD_DEFINITION
| SCHEMA
schema @tag(name: "contract1") @tag(name: "contract2") @tag(name: "contract3") {
query: Query
}
type ExampleType @key(fields: "field1 field2") {
field1: String! @tag(name: "contract1") @tag(name: "contract2") @override(from: "another-sub-graph")
field2: Int! @inaccessible
"""
Something interesting to add to the graph.
"""
field3: Int!
}
Thanks for the example! Indeed v2.1.0 had an issue when both schema and its extension were present. In general, I'd recommend to just add @link to the existing schema definition instead of creating separate extension but it is a valid case that should be handled. Thanks!
Fixed in v2.1.1