1. Is this a client library issue or a product issue?

Product issue

2. Did someone already solve this?

Not that I'm aware.

3. Do you have a support contract?

No

Environment details

• OS: MacOS Monterey
• Node.js version: 14
• npm version:
• release-please version:

Steps to reproduce

1. use draft GH release
2. make a release using github-release command
3. immediately issue a release-pr command

The release-pr will fail to find the drafted release and will immediately create a new "release PR".

From my investigation, this is due to the fact that "draft" GH releases are able to lazily create tags.
Which is to say that when you create a draft GH release, you can specify the tag name and ref, but those are not yet materialized in git; instead, they are only created when the release is published.
That said, "draft" GH releases can also point at existing tags and will "look" like any other GH release except with isDraft set to true.

For example, in my fork for this repo, I created 2 releases. One pointing at an existing tag (v14.6.0-exists) and another that will lazily create the tag (v14.6.1-lazy).

Now, if we issue the following GraphQL query (which is used by release-please here, except for the additional tagName field):

query ($name: String!, $owner: String!) {
  repository(owner: $owner, name: $name) {
    releases(orderBy: {field: CREATED_AT, direction: DESC}, first: 10) {
      nodes {
        name
        isDraft
        url
        tag {
          name
        }
        tagCommit {
          oid
        }
        tagName
      }
    }
  }
}

We obtain this:

{
  "data": {
    "repository": {
      "releases": {
        "nodes": [
          {
            "name": "v14.6.0-exists",
            "isDraft": true,
            "url": "https://github.com/plaflamme/release-please/releases/tag/untagged-1343daf7aae1ed4c3da5",
            "tag": {
              "name": "v14.6.0"
            },
            "tagCommit": {
              "oid": "faaf56cc557cbcfdbb881efe81e1da8e22441d31"
            },
            "tagName": "v14.6.0"
          },
          {
            "name": "v14.6.1-lazy",
            "isDraft": true,
            "url": "https://github.com/plaflamme/release-please/releases/tag/untagged-dd0aaa72f95f1a467bbe",
            "tag": null,
            "tagCommit": null,
            "tagName": "v14.6.1"
          }
        ]
      }
    }
  }
}

As you can see the tag and tagCommit values are missing for the "lazy" draft release. NOTE: you will not be able to reproduce this on my fork since "draft" releases are private.

This causes the iterator defined here to skip this release and makes release-pr fail to find the "previous" release.

Now the question is what should be the fix? Initially, I thought about removing the filter and properly handle the missing tagCommit and tag fields; but an alternate approach would be to make the github-release command actually create the tag in git and avoid these "lazy" releases altogether. This second approach seems more correct since the github-release command did indeed create the release and the repository should be tagged accordingly.

Any thoughts on what the fix should be here?