Error with GitLab Workflow Extension in VS Code

Suppress Connectivity Error from GitLab Workflow Extension in VS Code when private GitLab instance not reachable

Request: Is it possible to configure the GitLab Workflow Extension in VS Code to not automatically try to contact the GitLab instance its configured for every time VS Code is launched? If that’s not possible, is it possible to suppress errors about not being able to reach it?

Example of error when launching VS Code - it appears in lower right corner:

Details:
I am using the GitLab Workflow integration in VS Code. I have it configured with a Personal Access Token to access our private GitLab instance. It works great. Currently it appears to be configured to contact our GitLab server instance every time I launch VS Code. However, if I’m not connected to my company’s network, when I launch VS Code I get the above error. If I click on show logs I see the following:

2024-11-27T22:37:06:107 [error]: request to https://gitlab.example.org/api/graphql failed, reason: Hostname/IP does not match certificate's altnames: Host: gitlab.example.org. is not in the cert's altnames: DNS:*.wpengine.com, DNS:wpengine.com
    FetchError: request to https://gitlab.example.org/api/graphql failed, reason: Hostname/IP does not match certificate's altnames: Host: gitlab.example.org. is not in the cert's altnames: DNS:*.wpengine.com, DNS:wpengine.com
        at ClientRequest.<anonymous> (c:\Users\james\.vscode\extensions\node_modules\node-fetch\lib\index.js:1505:11)
        at ClientRequest.emit (node:events:531:35)
        at ClientRequest.emit (node:domain:488:12)
        at emitErrorEvent (node:_http_client:101:11)
        at TLSSocket.socketErrorListener (node:_http_client:504:5)
        at TLSSocket.emit (node:events:519:28)
        at TLSSocket.emit (node:domain:488:12)
        at emitErrorNT (node:internal/streams/destroy:169:8)
        at emitErrorCloseNT (node:internal/streams/destroy:128:3)
        at processTicksAndRejections (node:internal/process/task_queues:82:21)
2024-11-27T22:37:06:108 [warning]: Token validation failed in Language Server: (Token is invalid. Failed to check token: FetchError: request to https://gitlab.example.org/api/v4/personal_access_tokens/self failed, reason: Hostname/IP does not match certificate's altnames: Host: gitlab.example.org. is not in the cert's altnames: DNS:*.wpengine.com, DNS:wpengine.com. Reason: unknown). This can happen with OAuth token refresh. If the rest of the extension works, this won't be a problem.

The error is caused by two things:

  1. If I am not connected to my company’s network, the GitLab instance is inaccessible
  2. My company has public DNS configured so that any query returns a response (wildcard setup) - so even though gitlab.example.org isn’t accessible, doing a DNS lookup on it will return a result matching www.example.org. Of course, the certificate doesn’t match because its for a different domain.

Summary - error is expected if I’m not connected to my company’s network. The question is how to suppress/disable.

Is the error in the log causing UX troubles, or is it more about suppressing the error? You could switch accounts, and point to a public GitLab.com account while offline from the company environment.

Hello @dnsmichi,

Thank you for looking at this. This issue is just an annoyance - every time I launch VS Code and I’m not connected to work, the following error pops up in the lower right corner of the IDE:

Goal: Eliminate this pop up when launching VS Code.

If I am working on a repo which uses the work GitLab instance, I can understand it polling. However, even when I open a repo that’s not hosted on the work GitLab instance, I still get this error. It’s fine if it’s logged. I just don’t want the pop up error every time I open VS Code. I’m hoping there’s a way to suppress/prevent this error.

With multiple accounts, that sounds like I would have to have everything on a public or private GitLab instance. However, sometimes I just want to play with something locally (local git instance) and not necessarily create a GitLab repo for it. Think experimentation or prototyping. It doesn’t sound like the multiple accounts would help for this use case.

–Jim

Not ideal, but I would attempt to create an entry in your hosts file with the IP address of your Gitlab server on the company network and the appropriate FQDN that it resolves to from your company internal DNS. Since the hosts file would be checked before DNS when not connected to the company network, it would then fail to connect to any server whatsoever. Therefore the wildcard address would not be checked at this point and it wouldn’t cause certificate errors.

Obviously it would be better if the extension would give an option to disable communication temporarily, or you could also always just disable the extension when not in the office. Although the hosts entry would be better, configured once and forget.

Hello @iwalker,

That’s a good idea - I created a hosts entry and tried it out. Unfortunately, that appears to trade one error for another. Now, when I launch VS Code I get this error in the lower right corner:

–Jim

Ah well, worth a try :frowning:

I appreciate the idea - it’s always good to try things out. :slight_smile:

Plus the new error is more intelligible and smaller - a step in the right direction.

Eventually create an issue to discuss the popup and error handling with GitLab engineers.

1 Like