Returned HttpError from octokit.graphql request is not of type RequestError

[rickstaa]

Not sure if this is a bug or a problem with my code, but I'm trying to catch HttpErrors returned by the octokit.graphql package using the Request error class. I use the following code in this sandbox to do this:

import "./styles.css";
import dotenv from "dotenv";
import { getOctokit } from "@actions/github";
import { RequestError } from "@octokit/request-error";

dotenv.config();

const octokit = getOctokit(`${process.env.GITHUB_TOKEN}`);

export default function App() {
  const fetchGraphql = async () => {
    try {
      await octokit.graphql(
        `
        {
          repository(owner: "octokit", name: "graphql.js") {
            issues(last: 3) {
              edges {
                node {
                  title
                }
              }
            }
          }
        }
      `
      );
    } catch (error) {
      if (error instanceof RequestError) {
        console.log("A RequestError");
      } else if (error instanceof Error && error.name === "HttpError") {
        console.log("An error with name set to 'HttpError'");
      } else {
        console.log("Something else");
      }
    }
  };
  fetchGraphql();

  return (
    <div className="App">
      <h1>HttpError catch example</h1>
      <h2>The error returned from octokit is not a RequestError.</h2>
    </div>
  );
}

Unfortunately, the code always ends up at console.log("An error with name set to 'HttpError'"); statement. I, however, was under the impression that all the request errors returned by the octokit packages are of type RequestError (see https://github.com/octokit/request.js/blob/39d8b114ac1455dc0266705e546f981748935433/src/fetch-wrapper.ts#L3) and they code would end up at console.log("A RequestError"); statement.

[oscard0m]

Hi @rickstaa,

I'm sorry you are experiencing this issue. Also, thanks for the detailed explanation and for taking the time of sharing a CodeSandbok. It really helps a lot for reproducing the issue and debugging ❤️ .

---

It seems to be a mismatch of @octokit dependencies:

Using @octokit/graphql works for me: https://codesandbox.io/s/octokit-httperror-catch-bug-forked-ptp98l?file=/src/App.tsx (just in case it unblocks you in the meantime).

I'm digging into why using @actions/github's Octokit does not work. I will update this issue with more info ASAP.

[rickstaa]

@oscard0m Thanks a lot for your fast response and for providing me with the workaround. Feel free to let me know if you need more information.

[oscard0m]

@oscard0m Thanks a lot for your fast response and for providing me with the workaround. Feel free to let me know if you need more information.

@actions/github@5.0.3 is using @octokit/core@3.6.0 (as you can see here).

Apparently 3.6.0 version of octokit/core (which internally uses @octokit/graphql) does not support @octokit/request-error@3.0.0 but it supports the previous version: 2.1.0

The 2 options you have here are:

• Use @octokit/core or @octokit/graphql if you want to be up to date with latest releases
• Use the versions of @octokit accordingly to the version that uses @actions/github

---

Combinations of dependencies I've checked:

It works with:

• ✅ @octokit/core works: https://codesandbox.io/s/octokit-httperror-catch-bug-with-octokit-core-forked-0zf12c?file=/package.json
• ✅ @actions/github without importing @octokit/request-error: https://codesandbox.io/s/octokit-httperror-catch-bug-with-actions-github-forked-ltdokh?file=/src/App.tsx
• ✅ @actions/github + importing @octokit/request-error v2.1.0
• ❌ @actions/github + importing @octokit/request-error v3.0.0
• ✅ @octokit/core@latest + importing @octokit/request-error v3.0.0
• ❌ @octokit/core@3.6.0 + importing @octokit/request-error v3.0.0
• ✅ @octokit/core@3.6.0 + importing @octokit/request-error v2.1.0

---

[rickstaa]

@oscard0m Thanks a lot for giving me such a detailed answer. Until @actions/github@5.0.3 is updated to include a newer version of @actions/core, I will use @octokit/request-error v2.1.0.

[oscard0m]

I'm glad this information has been useful @rickstaa.

I'm closing this issue but feel free to re-open if there is something else we can do.