Null returned when applying filter on related field

(First of all, thanks to y’all for maintaining and developing this software; I love it so far :slight_smile: )
(Excuses in advance if I’ve misunderstood and the error I’m getting is actually intended behaviour)

TL;DR version
My schema contains: Reaction, Song and Transition, ReactionKind and the union type Reactable (being either Song or a Transition)
Reaction entries point to union type Reactable (being either Song or a Transition)

After having inserted reactions on both a Song and a Transition and I subsequently query for reactions only on Song entries (using the memberTypes filter), I get both errors and null values (corresponding to the Reaction pointing to the Transition) in my query-response. My expectation was that I would not get errors and no null in my response.

Long version
I’m running dgraph/standalone:latest on an empty database, and I initialize it with the following schema

type Song {
	ISRCIdentifier: String! @id @search(by: [hash])
}

type Transition {
	FromSong: Song!
	ToSong: Song!
}

union Reactable = Song | Transition

enum ReactionKind {
	Love
	Whoa
	Haha
	Eyes
}

type Reaction {
	ReactionKind: ReactionKind!
	ReactsOn: Reactable!
}

I then run the following mutations (to insert two songs, a transition between the two songs, and one comment on the song, and one comment on the transition)

mutation() {
  addSong(input: [
    {
      ISRCIdentifier: "USJI10301342",
    },
    {
      ISRCIdentifier: "USAT21601044",
    }
  ]) {
    song {
      ISRCIdentifier
    }
  }
}
mutation() {
  addTransition(input: [
    {
      FromSong: {
        ISRCIdentifier: "USJI10301342"
      },
      ToSong: {
        ISRCIdentifier: "USAT21601044",
      },
    }
  ]) {
    transition {
      FromSong {
        ISRCIdentifier,
      },
      ToSong {
        ISRCIdentifier,
      }
    }
  }
}
mutation() {
  addReaction(input: [
    {
      ReactionKind: Whoa,
      ReactsOn: {
        songRef: {
          ISRCIdentifier: "USJI10301342"
        }
      }
    },
    {
      ReactionKind: Love
      ReactsOn: {
        transitionRef: {
          FromSong: {
            ISRCIdentifier: "USJI10301342"
          },
          ToSong: {
            ISRCIdentifier: "USAT21601044"
          }
        }
      }
    }
  ]) {
    reaction {
      ReactionKind,
      ReactsOn {
        __typename,
        ... on Song {
          ISRCIdentifier
        }
        ... on Transition {
          FromSong {
            ISRCIdentifier
          }
          ToSong {
            ISRCIdentifier
          }
        }
      }
    }
  }
}

Now, I want to query for reactions on songs only

query {
  queryReaction {
    ReactionKind,
    ReactsOn(filter: {
      memberTypes: [Song]
    }) {
      __typename,
      ... on Song {
        ISRCIdentifier
      }
    }
  }
}

This query gives me the error “Non-nullable field ‘ReactsOn’ (type Reactable!) was not present in result from Dgraph. GraphQL error propagation triggered.”
The number of null values returned match the number of the entries I’ve inserted for the reaction on a transition.

My expectation
No null values and no errors.

Further context
Client-side, I obviously could just filter out the null values. However that scales poorly, and seems like a not-so-nice way to go about it :expressionless:

I found the solution for this myself, and I’m just going to write it up here, in case others hit the same “issue” (read: haven’t read up on the @cascade directive yet)

For others coming by this, have a look at the @cascade directive - it solved my problem!

2 Likes

Hi @mortenalbertsen,

Welcome to Dgraph Community !!

Thanks for reporting this. I was able to reproduce this. This looks like a bug with memberTypes filter. I am marking this as a bug and this will be looked after.

Although, cascade works fine in your example, the right behaviour should have been to not report any NULLS.

Do let us know if you have any other queries / questions.

1 Like

I am marking this as a bug and this will be looked after.
I’m glad to hear that it will be fixed, and thank you for taking the time to explain that the @cascade trick shouldn’t be necessary:)

Anyways, thanks for the help :slight_smile: I’m looking forward to the update :slight_smile: