Related document in richtext field not populated in afterRead hook when requested with GraphQL

[hdodov]

Link to reproduction

https://github.com/hdodov/payload/tree/bug-read-hook-population

To Reproduce

1. Checkout the reproduction repo: https://github.com/hdodov/payload/tree/bug-read-hook-population
2. Run npm run test:int _community (or Yarn)
3. You'll see one passing test and one failing test (check test/_community/int.spec.ts)

Describe the Bug

Context:

• There's a media collection with one uploaded file there
• There's a posts collection with one post that has the uploaded media file in the content of its richtext field
• There's an afterRead hook that does something with the URL of the uploaded media file in the richtext field, and therefore expects that the media file data is populated

Problem: The media file data is not populated when requested with the GraphQL API, even though it works as expected when using REST.

Here's what the hook looks like:

https://github.com/hdodov/payload/blob/bug-read-hook-population/test/_community/collections/Posts/index.ts#L17-L35

When performing a REST request, the document in the hook looks like this:

{
	"id": "64b8d84e2dc9fcaedf030db4",
	"content": [
		{
			"children": [
				{
					"text": ""
				}
			],
			"type": "upload",
			"value": {
				"id": "64b8d84e2dc9fcaedf030db2",
				"filename": "test-42.png",
				"mimeType": "image/png",
				"filesize": 11211,
				"width": 600,
				"height": 400,
				"createdAt": "2023-07-20T06:46:38.546Z",
				"updatedAt": "2023-07-20T06:46:38.546Z",
				"url": "/media/test-42.png"
			},
			"relationTo": "media"
		}
	],
	"createdAt": "2023-07-20T06:46:38.551Z",
	"updatedAt": "2023-07-20T06:46:38.551Z"
}

However, when performing the GraphQL request, the document looks like this:

{
	"id": "64b8d84e2dc9fcaedf030db4",
	"content": [
		{
			"children": [
				{
					"text": ""
				}
			],
			"type": "upload",
			"value": {
				"id": "64b8d84e2dc9fcaedf030db2"
			},
			"relationTo": "media"
		}
	],
	"createdAt": "2023-07-20T06:46:38.551Z",
	"updatedAt": "2023-07-20T06:46:38.551Z"
}

I thought that I had to specify the depth option, but as the docs say:

Depth has no effect in the GraphQL API, because there, depth is based on the shape of your queries.

…so I guess it's a bug, then. Here's my query:

{
  Posts { docs { content } }
}

---

It should be noted, however, that the document is populated in GraphQL, but only in the final result of the query:

{
	"data": {
		"Posts": {
			"docs": [
				{
					"content": [
						{
							"children": [
								{
									"text": ""
								}
							],
							"type": "upload",
							"value": {
								"id": "64b8ea2fd4e4c5bad1c7a568",
								"filename": "test-43.png",
								"mimeType": "image/png",
								"filesize": 11211,
								"width": 600,
								"height": 400,
								"createdAt": "2023-07-20T08:02:55.269Z",
								"updatedAt": "2023-07-20T08:02:55.269Z",
								"url": "/media/test-43.png"
							},
							"relationTo": "media"
						}
					]
				}
			]
		}
	}
}

It's just that it's populated after the afterRead hook, so the hook has no access to the data. Whereas in REST, the document is populated before the afterRead hook fires, so the hook can work with the data.

Payload Version

1.11.2

[JarrodMFlesch]

Hey @hdodov thanks for bringing this up. I am unsure what the answer is. Here is a simplified version, disregarding RTE all together that has the same outcome:

export const PostsCollection = {
  slug: 'posts',
  hooks: {
    afterRead: [
      ({ doc }) => {
        const tagName = doc?.tag ? doc.tag.name : null;
        // ^ issue is here, GraphQL sets depth to 0 _always_, REST is set to 1 by default
        // so REST and GraphQL return different data

        return {
          ...doc,
          tagName,
        };
      },
    ],
  },
  fields: [
    {
      name: 'tag',
      type: 'relationship',
      relationTo: 'tags',
    },
    {
      type: 'text',
      name: 'tagName',
    },
  ],
};

In REST a GET request to https://cms.com/api/posts will return:

{
  "docs": [
    {
      "id": "post-id",
      "tag": {
        "id": "tag-id",
        "name": "tag-name",
      },
      "tagName": "tag-name",
    },
  ]
}

A GraphQL like so:

query {
  Posts {
    docs {
      id
      tag {
        id
        name
      }
      tagName
    }
  }
}

will return:

{
  "docs": [
    {
      "id": "post-id",
      "tag": {
        "id": "tag-id",
        "name": "tag-name",
      },
      "tagName": null,
    },
  ]
}

In order to align them, we would need to pass depth through from the GraphQL operation wrappers. Is this something we want to do? I imagine we explicitly set it to depth: 0 for performance reasons? Maybe this is something we need to call out in our docs? Not sure what the move is here.

I brought it up in our core-dev discord channel too.

[jmikrut]

OK so I just looked into this and I have some answers.

First up, this is going to be quite difficult to achieve, but it should be possible to implement and I do believe we should implement a way to flatten this logic.

The discrepancy is caused because in REST and Local APIs, we leverage the depth parameter, but in GraphQL, we do not. It's up to the shape of your GraphQL query itself to populate accordingly.

The GraphQL field resolvers for relationship, upload, and richText are what is responsible for populating data accordingly, but the problem there is that those resolvers are fired after the Payload operation (and the hooks) are fired.

To match REST to GraphQL here, we need to remove the "population" logic from field resolvers themselves and introduce a way to pass the GraphQL info from the top-level find resolver into the Payload operation itself, so that there, the operation logic (theafterRead field lifecycle event in specific) can be responsible for "populating" relationships / uploads / rich text documents just as it is responsible in the REST / Local APIs.

We would then recurse into the GraphQL info just as we do with field data itself within the afterRead hook, and in GraphQL, we would rely on that instead of the depth argument.

This will be a relatively large lift, and I'm not sure that we will be able to commit to this within the coming month or so. Afterward, I do think that this will be a codebase simplification actually, so I think it's worth it to tackle.

Is there another way to accomplish what you're looking to do in the meantime?

I'm going to add this to our Roadmap, but in the meantime, I think we should figure out another workaround for you here. What do you think?

[hdodov]

I think I'm just going to use REST for the time being. Worst comes to worst, I could always set up a custom API endpoint where I use the local API to achieve whatever I want, so I believe I have options.

I'm just fairly new to GraphQL and sometimes I'm not sure if the problem lies in my limited knowledge of it or in Payload's handling of queries.

Glad to hear you're adding this to your roadmap!