Fetching variables isn't handling 404 error requests for `Variables` in GHES versions before 3.8

[planetsLightningArrester]

Describe the bug Whenever I open a workflow connected to GHES 3.7, I get the following error message (sensitive data hidden by ***). This is because the Variables support was introduced on GHES 3.8.

Failure to retrieve variables:  Cs [HttpError]: Not Found
{
  status: 404,
  response: {
    url: 'https://***/api/v3/repos/***/***/actions/variables?per_page=100',
    status: 404,
    headers: {
      'access-control-allow-origin': '*',
      'access-control-expose-headers': 'ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset',
      'content-encoding': 'gzip',
      'content-security-policy': "default-src 'none'",
      'content-type': 'application/json; charset=utf-8',
      date: 'Wed, 10 Apr 2024 16:41:09 GMT',
      'referrer-policy': 'origin-when-cross-origin, strict-origin-when-cross-origin',
      server: 'GitHub.com',
      'strict-transport-security': 'max-age=31536000; includeSubdomains',
      'transfer-encoding': 'chunked',
      'x-accepted-oauth-scopes': 'repo',
      'x-content-type-options': 'nosniff',
      'x-frame-options': 'deny',
      'x-github-enterprise-version': '3.7.5',
      'x-github-media-type': 'github.v3; format=json',
      'x-github-request-id': '***',
      'x-oauth-client-id': '***',
      'x-oauth-scopes': 'repo, workflow',
      'x-ratelimit-limit': '5000',
      'x-ratelimit-remaining': '4982',
      'x-ratelimit-reset': '1712767559',
      'x-ratelimit-resource': 'core',
      'x-ratelimit-used': '18',
      'x-runtime-rack': '0.033786',
      'x-xss-protection': '0'
    },
    data: {
      message: 'Not Found',
      documentation_url: 'https://docs.github.com/[email protected]/rest'
    }
  },
  request: {
    method: 'GET',
    url: 'https://***/api/v3/repos/***/***/actions/variables?per_page=100',
    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': 'VS Code GitHub Actions (0.26.2) octokit-rest.js/19.0.7 octokit-core.js/4.1.0 Node.js/18.18.2 (linux; x64)',
      authorization: 'token [REDACTED]'
    },
    request: { hook: [Function: bound bound e] }
  }
}

To Reproduce Steps to reproduce the behavior:

1. Log into a GitHub Enterprise server version 3.7 in VSCode
2. Open a workflow file related to a GH project
3. See several 404 errors trying to reach https://<ghes_url>/api/v3/repos/<user>/<repo>/actions/variables

Expected behavior Either detect whether the server supports this request or waive this error without throwing it considering that the server may not support this.

Screenshots If applicable, add screenshots to help explain your problem.

Package/Area

• [ ] Expressions
• [ ] Workflow Parser
• [ ] Language Service
• [X] Language Server

Package Version v0.3.9

Additional context I recently reported github/vscode-github-actions#313. I noticed their repo uses @actions/languageserver, and after some investigation, I found that the root cause for unhandled 404 error requests for Variables might be related to the code below - based on the error message I'm getting (line 142).

https://github.com/actions/languageservices/blob/5dbaa884dbd889a68eb184eb0f28c0f6618264ee/languageserver/src/context-providers/variables.ts#L127-L145

The only place I can see this function being called is inside getRemoteVariables, which is also only used in the code below (line 47).

https://github.com/actions/languageservices/blob/5dbaa884dbd889a68eb184eb0f28c0f6618264ee/languageserver/src/context-providers/variables.ts#L46-L97

However, the error should be caught by:

https://github.com/actions/languageservices/blob/5dbaa884dbd889a68eb184eb0f28c0f6618264ee/languageserver/src/context-providers/variables.ts#L91-L97

And the error would be waived. But it looks like the error isn't handled properly for e.name == "HttpError" && e.status == 404 and the error is thrown anyway.

Blaming the file, I see 41436c657094f18fa3c34c46bc2bbeee88403d0d might have shadowed the case where the context is still returned and a log message is displayed. I'm not 100% confident of this because I don't know if the error thrown for 404 is NOT a RequestError, but that's the only reason I could think of.

Thanks for the language server :) amazing work here