Relationship field query errors out for anonymous when set to some non-published post

[mdrayer]

Say you have a post relationship field called "Related Content" in a Post custom fields group (say "Post Fields"). If a selected post within that field is set to private, draft, or some other state where the anonymous user cannot view it; the query will return an error. I would instead expect the system to simply return null (which it does) and give no errors.

Example query:

{
  postBy(postId: 13) {
    status
    title
    postFields {
      relatedContent {
        __typename
        ... on Post {
          id
          title
        }
      }
    }
  }
}

Result:

{
  "errors": [
    {
      "message": "Internal server error",
      "category": "internal",
      "locations": [
        {
          "line": 6,
          "column": 7
        }
      ],
      "path": [
        "postBy",
        "postFields",
        "relatedContent",
        0
      ]
    }
  ],
  "data": {
    "postBy": {
      "status": "publish",
      "title": "Some Post",
      "postFields": {
        "relatedContent": [
          null
        ]
      }
    }
  }
}

Tested on:

• WordPress 5.2.4
• Advanced Custom Fields 5.8.6
• WP GraphQL 0.4.0
• WPGraphQL for ACF 0.3.0

[mdrayer]

@jasonbahl let me know if you need any more information here to replicate this.

[peterjanes]

I've just replicated this as well, with an unpublished post (using a custom post type, if that helps isolate the issue). I realized it when I didn't see the error running the same query in an admin user session.

[jasonbahl]

@mdrayer @peterjanes I'm not currently able to replicate this. I've tried on WPGraphQL v0.4.0 and the upcoming WPGraphQL v0.5.0.

Maybe I'm missing a detail with my Field Group or Field configuration?

Here's what I'm doing to try and replicate, and I'm not getting errors:

• I have a Field Group called relationshipTest assigned to Posts and a Relationship field.
• I created a Post called "Delete Me" and set it as the value of the relationship field
• I can query this relationship just fine (see below)
• I then deleted the "Delete Me" Post, but I left the ID set as the value of the relationship field
• I then queried again, and didn't receive an error, just an empty relationship array (see 2nd screenshot)

Perhaps you can share your Field Group registration(s) with me so I can replicate exactly?

[mdrayer]

The issue isn't with deleted posts, it is with posts that are set to private or draft. For instance, instead of deleting the "Delete Me" post, set it to Private and run the query again as an anon user.

[jasonbahl]

Ah. 🤦‍♂ I guess I need to read the details better. Let me try again 👀

[jasonbahl]

Ah. Ok. Makes much more sense now that I try with a private post.

I think the best thing to do here is going to be to adjust the shape of this field to return the node one level deeper.

Like:

{
  relationship {
     node {
        ...PostFields
     }
  }
}

The reason the error is getting thrown is because it's expecting to resolve to a Type, but if we nest it a level, the field that leads to the node can resolve to null and not try and process the actual object and throw the error.

I'll play with this and see what I can come up with. 🤔

[drewbaker]

Just ran into this with the Post Link field type, linking to a Drafted page.

[mdrayer]

This is still happening with WP GraphQL v0.6.1, WP GraphQL for ACF v0.3.1.

[patibugaj]

I have the same issue. Any working solution?

[binnyFriedman]

Hello, thanks for the awesome work.
I'm having the same issue, would it help to check for permission on that level in the resolver and return only posts that fit the criteria?

[drewbaker]

Just ran into this with a Relationship field type.

Also I think it's related to this issue too: #100

[drewbaker]

Just to say it, this is an incredibly frustrating bug. It's very hard to discover this in development, and easy for the user to draft something and then this breaks the site in some other unrelated place. What's worse is GraphiQL will show the query working, so it's really hard to track it down in the real world. Legit spent 6 hours today only to come back to this error from a year ago that I already knew about. 🤦‍♂

[drewbaker]

Adding define( 'GRAPHQL_DEBUG', true ); into the plugin gets me this error:

{
  "errors": [
    {
      "debugMessage": "Abstract type Page_Acfpagemeta_Director must resolve to an Object type at runtime for field Page_Acfpagemeta.director with value \"instance of WPGraphQL\\Model\\Post\", received \"null\". Either the Page_Acfpagemeta_Director type should provide a \"resolveType\" function or each possible type should provide an \"isTypeOf\" function.",
      "message": "Internal server error",
      "extensions": {
        "category": "internal"
      },
      "locations": [
        {
          "line": 16,
          "column": 28
        }
      ],
      "path": [
        "nodeByUri",
        "children",
        "nodes",
        9,
        "acfPageMeta",
        "director",
        0
      ]
    }
  ],
  "data": {...}

[ricokahler]

I ran into this bug with the latest WPGraphQL (v0.11.0 at the time of this writing) and the current WPGraphQL ACF plugin (v0.3.5) and I've been experiencing it for a while now. It really make it hard to use ACF with Gatsby and gatsby-source-graphql because there is no error handling there.

I've resulted in writing a wrapper around node-fetch and passing that wrapped fetch to the options of gatsby-source-graphql. This wrapped fetch intercepts the response and removes the benign errors caused by this bug. This works for me but it's extremely frustrating.

Any help would be greatly appreciated!

[jacobarriola]

Just ran into this with the Relationship field as well. 👀

[phendrick]

I've worked around this with a WP filter which calls get_posts() with the relationship's value; get_posts only returns published posts by default so getting the ID's from that collection will remove draft/deleted posts.

add_filter( 'acf/load_value/type=relationship', function( $value, $post_id, $field ) {
    if( !$value ) return [];

    $posts = get_posts( ['post_type' => 'any', 'post__in' => $value ]);

    return array_map( function($post ) {
        return $post->ID;
    }, $posts );
}, 10, 3);

[jasonbahl]

I believe what needs to happen to resolve this is to update the resolver for relationship fields to use the DataLoader instead of loading posts directly.

[jasonbahl]

👋🏻 This is resolved in the upcoming v0.6.0 release.

More information here: #173 (comment)