🐛 [Bug] Missing notifications resolver

Created by: Tirokk

Authored by roschaefer Aug 21, 2019 Closed Aug 30, 2019

---

🐛 Bugreport

If the User resolver resolves a user without notifications (which is the case for all top-level resolvers that don't use neo4j-graphql-js) then the User.notifications resolver will return undefined.

Steps to reproduce the behavior

1. Login as user with id u4 to get a JWT token
2. Run the following mutation:

mutation {
  UpdateUser(id: "u4", name:"Whatever")  {
    name
    notifications {
      read
      id
    }
  }
}

3. See error "Resolve function for "User.notifications" returned undefined":

{
  "errors": [
    {
      "message": "Resolve function for \"User.notifications\" returned undefined",
      "locations": [
        {
          "line": 4,
          "column": 5
        }
      ],
      "path": [
        "UpdateUser",
        "notifications"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR"
      }
    }
  ],
  "data": {
    "UpdateUser": null
  }
}

Expected behavior

If the schema declares the User.notifications relation, then it should return a list of notifications for that user. However, why would sb. get a list of notifications for anyone else than the current user? There should be a top-level Notification query which automatically filters for the current user.

Additional context

The optimal solution would be to remove this line from the schema: https://github.com/Human-Connection/Human-Connection/blob/master/backend/src/schema/types/type/User.gql#L27

Then manually declare the Notification query here: https://github.com/Human-Connection/Human-Connection/blob/master/backend/src/schema/types/type/Notification.gql

Also change the query used in the frontend: https://github.com/Human-Connection/Human-Connection/blob/master/webapp/graphql/User.js#L78

It should not use a nested resolver like { currentUser { notifications { ... } } instead it should only query the { Notification } which is automatically filtered for those notifications of the current user.

@Tirokk @ogerly stumbled over this bug in our pairing yesterday