Projects without a repo report nil for paginatedTree: NoMethodError / undefined method 'cursor'

Summary

Projects without a repo return a nil value for GraphQL queries with paginatedTree. This was reported by a very large GitLab Ultimate customer after upgrading from 15.1.6 to 15.4.6.

Steps to reproduce

1. On https://gitlab.com/-/graphql-explorer
2. Try this query:

{  project(fullPath: "gitlab-gold/katrinleinweber-kl-tests/zd-323351-empty") {
    repository {
      paginatedTree {
        pageInfo {
          endCursor
          startCursor
          }        }      }    }  }

Example project: https://gitlab.com/gitlab-gold/katrinleinweber-kl-tests/zd-323351-empty

Non-minimal query variant & trivia

The customer used a different query, which probably included their instance's empty, auto-generated gitlab-instance-…/Monitoring project. A simplified version of that is:

{  projects(last: 5) {
    nodes {
      id
      fullPath
      repository {
        paginatedTree {
          pageInfo {
            endCursor
            startCursor
          }        }      }    }  }}

This is also reproducible on GitLab.com, but due to project deletions last: 5 might need to be increased. It works as of creation of this issue, but 4 yields a correct response. Curiously, this means that the currently 5th-oldest project on GitLab.com has no repo 🤓

Can also be reproduced on a test instance (customer & me tried v15.4.6) that started out with the empty gitlab-instance-…/Monitoring project. Narrowing the problem source down to paginatedTree was done by switching last: … to first: 1 in the query, and then alternating between creating:

• 1 new repo with a ReadMe or from a template, and
• 1 without any template or ReadMe.

Repeating the query after each project creation "toggles" between the erroneous query result.

1. Also, removing the paginatedTree {…} part from the query or deleting the empty project results in non-erroneous output.

The latter workaround (esp. when it's an unused gitlab-instance-…/Monitoring project which is deprecated, anyway) is a straight-forward workaround, IMHO.

Creating a place-holder repo with just a small ReadMe.md in other empty projects that can't be deleted, should also be a possible workaround.

What is the current bug behavior?

"message": "Internal server error" but no gprd logs, as far as I could find. x-request-ids & Sentry link for further digging can be found in ZD 394401.

What is the expected correct behavior?

A non-error response with the expected data for the project(s).

Relevant logs and/or screenshots

See ZD 394401 for full details, esp. trace.txt for pasting into RubyMine.

1. (or last?) backtrace item is paginated_tree_resolver.rb:41. b4a91d changed node near that, so #348909 (closed) might be related to this issue as well.

I checked the whole backtrace for recent changes with

/bin/cat trace.txt | while read -r line
  do
    file=$(echo $line | cut -d':' -f1)
    lnum=$(echo $line | cut -d':' -f2)

    echo -e "\n$line"
    git blame $file | head -$lnum | tail -1
  done

but found none.

Further Git digging

$ git diff v15.1.6-ee v15.4.6-ee | rg 'paginatedTree'

+      paginatedTree(path: $path, ref: $ref) {
# https://gitlab.com/gitlab-org/gitlab/-/blame/v15.4.6-ee/app/graphql/queries/repository/path_last_commit.query.graphql#L7

+        const lastCommit = data.project?.repository?.paginatedTree?.nodes[0]?.lastCommit;
# https://gitlab.com/gitlab-org/gitlab/-/blame/v15.4.6-ee/app/assets/javascripts/repository/components/last_commit.vue

+          paginatedTree: {
# https://gitlab.com/gitlab-org/gitlab/-/blame/v15.4.6-ee/spec/frontend/repository/components/last_commit_spec.js

Output of checks

This bug happens on GitLab.com

Possible fixes