graphql
graphql copied to clipboard
Querying for connections fails when using interfaces in type definition
Describe the bug
When using the where: connection
filter option, and the connection is to an interface, the query fails
Type definitions
type Screening {
id: ID! @id
title: String
beginsAt: DateTime!
movie: ScreenableMeta! @relationship(type: "SCREENS_MOVIE", direction: OUT)
}
interface ScreenableMeta {
id: ID! @id
spokenLanguage: String!
subtitlesLanguage: String!
premiere: DateTime!
locale: Locale!
}
type NorwegianScreenableMeta implements ScreenableMeta {
id: ID! @id
spokenLanguage: String!
subtitlesLanguage: String!
premiere: DateTime!
locale: Locale!
ediNumber: String!
}
and query:
query queryScreenings {
screenings(
where: {
movieConnection: {
node: {
id: "52a26830-86f8-47b5-bcb5-4ebbf1df2a01"
}
}
}
) {
beginsAt
movie {
id
}
}
}
To Reproduce
- Given the schema above and query above
- The server returns an
INTERNAL_SERVER_ERROR
with the following stacktrace
{
"errors": [
{
"message": "Cannot read property 'name' of undefined",
"locations": [
{
"line": 6,
"column": 3
}
],
"path": [
"screenings"
],
"extensions": {
"code": "INTERNAL_SERVER_ERROR",
"exception": {
"stacktrace": [
"TypeError: Cannot read property 'name' of undefined",
" at /Users/trond/projects/tenants/api/node_modules/@neo4j/graphql/dist/translate/where/create-where-and-params.js:138:55",
" at Array.forEach (<anonymous>)",
" at reducer (/Users/trond/projects/tenants/api/node_modules/@neo4j/graphql/dist/translate/where/create-where-and-params.js:135:41)",
" at Array.reduce (<anonymous>)",
" at createWhereAndParams (/Users/trond/projects/tenants/api/node_modules/@neo4j/graphql/dist/translate/where/create-where-and-params.js:193:60)",
" at translateTopLevelMatch (/Users/trond/projects/tenants/api/node_modules/@neo4j/graphql/dist/translate/translate-top-level-match.js:76:61)",
" at translateRead (/Users/trond/projects/tenants/api/node_modules/@neo4j/graphql/dist/translate/translate-read.js:48:67)",
" at resolve (/Users/trond/projects/tenants/api/node_modules/@neo4j/graphql/dist/schema/resolvers/read.js:31:64)",
" at Object.screenings (/Users/trond/projects/tenants/api/node_modules/@neo4j/graphql/dist/schema/resolvers/wrapper.js:66:12)",
" at /Users/trond/projects/tenants/api/node_modules/@opentelemetry/instrumentation-graphql/build/src/utils.js:258:38"
]
}
}
}
],
"data": null
}
Expected behavior Return all screenings that are connected to the movie specified by the id
System (please complete the following information):
- OS: macOS m1
- Version: @neo4j/[email protected]
- Node.js version: 16.3.0
Additional context If we don't use interfaces, this works as expected
Many thanks for raising this bug report @megatrond. :bug: We will now attempt to reproduce the bug based on the steps you have provided.
Please ensure that you've provided the necessary information for a minimal reproduction, including but not limited to:
- Type definitions
- Resolvers
- Query and/or Mutation (or multiple) needed to reproduce
If you have a support agreement with Neo4j, please link this GitHub issue to a new or existing Zendesk ticket.
Thanks again! :pray:
For more context, this query also fails with the same error:
query queryScreenings {
screenings(
where: {
movieConnection: {
node: {
_on: {
NorwegianScreenableMeta: {
id: "52a26830-86f8-47b5-bcb5-4ebbf1df2a01"
}
}
}
}
}
) {
beginsAt
movie {
id
}
}
}
Simplified schema definition to reproduce the issue:
type Screening {
id: ID! @id
interface: MyInterface! @relationship(type: "INTERFACE_CONNECTION", direction: OUT)
}
interface MyInterface {
id: ID! @id
}
type MyImplementation implements MyInterface {
id: ID! @id
}
and query:
query queryScreening {
screenings(where: { interfaceConnection: { node: { id: "some-id" } } }) {
id
interface {
id
}
}
}
We've been able to confirm this bug using the steps to reproduce that you provided - many thanks @megatrond! :pray: We will now prioritise the bug and address it appropriately.
This bug report has been assigned high priority to fix. If you wish to contribute a fix, please branch from master
and submit your PR with the base set to master
. Thanks!
@megatrond, I realise this has been open for a little while, but is this a blocker for you? This is turning out to be a nastier bug than we would have hoped.
Not blocking, we found a way around it for now 👍
Not blocking, we found a way around it for now 👍
That's good to hear, apologies for the slow follow-up!
Hello everyone,
I assume that this is not fixed, is it?
Hi @farhadnowzari @megatrond This is actually fixed in version 3.6.0 as part of a major refactor on connection translation. Sorry, we didn't realize this was fixed as part of that and didn't notify, I'll close this issue