Extension is spamming user with "Failed to fetch jobs for pipeliene" if MR pipeline is missing

Summary

Disclaimer: This bug needs rare conditions to manifest itself, but it so happened that these conditions are now happening for master branch of the gitlab-org/gitlab project.

Steps to reproduce

1. Setup your extension with gitlab.com token
2. Open https://gitlab.com/gitlab-org/gitlab project
3. Checkout the master branch
4. See an error pop up every 30 seconds

What is the current bug behavior?

The extension shows an error message when we fail to fetch a pipeline during our polling.

What is the expected correct behavior?

We should log the error and ignore the detached pipeline and use the normal pipeline instead.

Relevant logs and/or screenshots

The screenshot is in summary, the log is:

{
  "userMessage": "Failed to fetch jobs for pipeline.",
  "errorMessage": "404 - \"{\\\"message\\\":\\\"404 Not found\\\"}\"",
  "stack": [
    "StatusCodeError: 404 - \"{\\\"message\\\":\\\"404 Not found\\\"}\"",
    "\tat new StatusCodeError (/Users/tomas/workspace/gitlab-vscode-extension/node_modules/request-promise-core/lib/errors.js:32:15)",
    "\tat /Users/tomas/workspace/gitlab-vscode-extension/node_modules/request-promise-core/lib/plumbing.js:97:41",
    "\tat tryCatcher (/Users/tomas/workspace/gitlab-vscode-extension/node_modules/bluebird/js/release/util.js:16:23)",
    "\tat Promise._settlePromiseFromHandler (/Users/tomas/workspace/gitlab-vscode-extension/node_modules/bluebird/js/release/promise.js:547:31)",
    "\tat Promise._settlePromise (/Users/tomas/workspace/gitlab-vscode-extension/node_modules/bluebird/js/release/promise.js:604:18)",
    "\tat Promise._settlePromiseCtx (/Users/tomas/workspace/gitlab-vscode-extension/node_modules/bluebird/js/release/promise.js:641:10)",
    "\tat _drainQueueStep (/Users/tomas/workspace/gitlab-vscode-extension/node_modules/bluebird/js/release/async.js:97:12)",
    "\tat _drainQueue (/Users/tomas/workspace/gitlab-vscode-extension/node_modules/bluebird/js/release/async.js:86:9)",
    "\tat Async._drainQueues (/Users/tomas/workspace/gitlab-vscode-extension/node_modules/bluebird/js/release/async.js:102:5)",
    "\tat Immediate._onImmediate (/Users/tomas/workspace/gitlab-vscode-extension/node_modules/bluebird/js/release/async.js:15:14)",
    "\tat processImmediate (internal/timers.js:456:21)",
    "\tat process.callbackTrampoline (internal/async_hooks.js:120:14)"
  ]
}

Root cause

Since we implemented the #228 (closed), we are now fetching MR for the active branch and if the branch has got an MR, we'll try to fetch a detached pipeline for the MR.

This logic looks for an MR for the master branch in the gitlab-org/gitlab project.

curl -H "PRIVATE-TOKEN: $TOKEN" "https://gitlab.com/api/v4/projects/278964/merge_requests?state=opened&source_branch=master" | jq .

This returns a list of MR's and we use the first one with IID 58916.

curl -H "PRIVATE-TOKEN: $TOKEN" "https://gitlab.com/api/v4/projects/278964/merge_requests/58916/pipelines" | jq .

We get a list of pipelines and we choose the first one:

curl -H "PRIVATE-TOKEN: $TOKEN" "https://gitlab.com/api/v4/projects/278964/pipelines/283736921/jobs" | jq .

This call returns 404. This is completely unexpected and points to a corrupted database. That's why we throw an error. The problem is that it bombards the user with an error notification every 30s.

Possible fixes

See "What is the expected correct behavior?".