nodeByUri resolving incorrectly when permalinks are set to a custom structure

[jasonbahl]

Description

When querying for nodeByUri and passing a non-existing path as the uri, a ContentType node is returned instead of null.

This is happening on the 1.14.0 release branch (and develop, which is yet to be released code) but is NOT happening on the latest release 1.13.10.

Steps to reproduce

1. activate WPGraphQL v1.14.0 from the release branch or develop branch
2. set your permalink structure to Custom Structure: > /posts/%postname%/
3. save your permalinks
4. execute the following query:

{
  nodeByUri(uri: "/whatever - shouldn't exist even with spaces") {
    uri
    id
    __typename
  }
}

5. see the response return a node of the ContentType type (this is a bug as null is the expected response)

Additional context

If we follow the same steps to reproduce in version 1.13.10, we get a null response as expected:

---

Behavior (still unexpected) changes when you change the values of these settings:

---

Possibly related: #2260 and corresponding PR: #2261

WPGraphQL Version

1.14.0 (unreleased)

WordPress Version

6.1.1

PHP Version

8.1.9

Additional enviornment details

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have disabled ALL plugins except for WPGraphQL.

• Yes
• My issue is with compatibility with a specific WordPress plugin, and I have listed all my installed plugins (and version info) above.

[justlevine]

Surfacing some notes from slack:

1. What's happening is that instead of the URI getting marked as an error (for not matching the rewrite rules), it falls back to the Home Page. In the OP example, this is the Posts ContentType, but if you explicitly set a page as the Home Page, it will return that instead.

2. The query args that are passed into our local WP_Query call are different than whats passed to WP::query_posts(). This seems to be due at least in part to our NodeResolver::parse_request() call missing logic that I guess was stripped out as extraneous with the old approach.

3. There's a compounding factor where querying nodeByUri multiple times in the same request results in stale data in the NodeResolver class properties that also messes with the results. Needs more sleuthing.