diff --git a/app/assets/javascripts/boards/index.js b/app/assets/javascripts/boards/index.js
index 5cc0ee8b7a999a26f4f6537245eddd3c6978bc8a..382119715897522cbc324fe00a7078a0d7b470dc 100644
--- a/app/assets/javascripts/boards/index.js
+++ b/app/assets/javascripts/boards/index.js
@@ -332,6 +332,8 @@ export default () => {
             class="btn btn-success gl-ml-3"
             type="button"
             data-placement="bottom"
+            data-track-event="click_button"
+            data-track-label="board_add_issues"
             ref="addIssuesButton"
             :class="{ 'disabled': disabled }"
             :title="tooltipTitle"
diff --git a/app/assets/javascripts/issue.js b/app/assets/javascripts/issue.js
index ad0147bdca2a470456bf9a11e5fba80d3abb46ab..0a0cfe918afffbe38c3f3fc185c42befce407d5f 100644
--- a/app/assets/javascripts/issue.js
+++ b/app/assets/javascripts/issue.js
@@ -100,6 +100,13 @@ export default class Issue {
   initIssueBtnEventListeners() {
     const issueFailMessage = __('Unable to update this issue at this time.');
 
+    $('.report-abuse-link').on('click', e => {
+      // this is needed because of the implementation of
+      // the dropdown toggle and Report Abuse needing to be
+      // linked to another page.
+      e.stopPropagation();
+    });
+
     // NOTE: data attribute seems unnecessary but is actually necessary
     return $('.js-issuable-buttons[data-action="close-reopen"]').on(
       'click',
diff --git a/app/assets/javascripts/merge_request.js b/app/assets/javascripts/merge_request.js
index 8322d36faeed076d38906d85e7b5c6990c8af609..79a4c3700ef4558808824fd45914deafc1f539b1 100644
--- a/app/assets/javascripts/merge_request.js
+++ b/app/assets/javascripts/merge_request.js
@@ -66,6 +66,14 @@ MergeRequest.prototype.showAllCommits = function() {
 
 MergeRequest.prototype.initMRBtnListeners = function() {
   const _this = this;
+
+  $('.report-abuse-link').on('click', e => {
+    // this is needed because of the implementation of
+    // the dropdown toggle and Report Abuse needing to be
+    // linked to another page.
+    e.stopPropagation();
+  });
+
   return $('.btn-close, .btn-reopen').on('click', function(e) {
     const $this = $(this);
     const shouldSubmit = $this.hasClass('btn-comment');
diff --git a/app/assets/javascripts/notes/components/note_actions/reply_button.vue b/app/assets/javascripts/notes/components/note_actions/reply_button.vue
index 208293428fa0fb3b78c0ad83cb9e9a891ddf4261..f19b7667fb239373ae9532ab8d7eba8e1a118809 100644
--- a/app/assets/javascripts/notes/components/note_actions/reply_button.vue
+++ b/app/assets/javascripts/notes/components/note_actions/reply_button.vue
@@ -1,11 +1,10 @@
 <script>
-import { GlTooltipDirective, GlDeprecatedButton, GlIcon } from '@gitlab/ui';
+import { GlTooltipDirective, GlButton } from '@gitlab/ui';
 
 export default {
   name: 'ReplyButton',
   components: {
-    GlIcon,
-    GlDeprecatedButton,
+    GlButton,
   },
   directives: {
     GlTooltip: GlTooltipDirective,
@@ -15,17 +14,17 @@ export default {
 
 <template>
   <div class="note-actions-item">
-    <gl-deprecated-button
+    <gl-button
       ref="button"
       v-gl-tooltip
-      class="note-action-button"
       data-track-event="click_button"
       data-track-label="reply_comment_button"
-      variant="transparent"
+      category="tertiary"
+      size="small"
+      icon="comment"
       :title="__('Reply to comment')"
+      :aria-label="__('Reply to comment')"
       @click="$emit('startReplying')"
-    >
-      <gl-icon name="comment" class="link-highlight" />
-    </gl-deprecated-button>
+    />
   </div>
 </template>
diff --git a/app/assets/javascripts/vue_shared/components/gl_mentions.vue b/app/assets/javascripts/vue_shared/components/gl_mentions.vue
index 00bc46257ed5d1f8f09ba1cbe86379c9d735d407..da4b0aedef5cbbdd29cdef658dcd1190df6caee6 100644
--- a/app/assets/javascripts/vue_shared/components/gl_mentions.vue
+++ b/app/assets/javascripts/vue_shared/components/gl_mentions.vue
@@ -9,6 +9,7 @@ const AutoComplete = {
   Issues: 'issues',
   Labels: 'labels',
   Members: 'members',
+  MergeRequests: 'mergeRequests',
 };
 
 function doesCurrentLineStartWith(searchString, fullText, selectionStart) {
@@ -99,6 +100,14 @@ const autoCompleteMap = {
         ${icon}`;
     },
   },
+  [AutoComplete.MergeRequests]: {
+    filterValues() {
+      return this[AutoComplete.MergeRequests];
+    },
+    menuItemTemplate({ original }) {
+      return `<small>${original.reference || original.iid}</small> ${escape(original.title)}`;
+    },
+  },
 };
 
 export default {
@@ -139,6 +148,13 @@ export default {
               : `~${original.title}`,
           values: this.getValues(AutoComplete.Labels),
         },
+        {
+          trigger: '!',
+          lookup: value => value.iid + value.title,
+          menuItemTemplate: autoCompleteMap[AutoComplete.MergeRequests].menuItemTemplate,
+          selectTemplate: ({ original }) => original.reference || `!${original.iid}`,
+          values: this.getValues(AutoComplete.MergeRequests),
+        },
       ],
     });
 
diff --git a/app/assets/javascripts/vue_shared/components/markdown/field.vue b/app/assets/javascripts/vue_shared/components/markdown/field.vue
index 29165c2b1e01daf5a4f960054171a4bbecebf46f..9e1943f88b08364f438ab62ddf234ea987a2048e 100644
--- a/app/assets/javascripts/vue_shared/components/markdown/field.vue
+++ b/app/assets/javascripts/vue_shared/components/markdown/field.vue
@@ -169,7 +169,7 @@ export default {
       emojis: this.enableAutocomplete,
       members: this.enableAutocomplete && !this.glFeatures.tributeAutocomplete,
       issues: this.enableAutocomplete && !this.glFeatures.tributeAutocomplete,
-      mergeRequests: this.enableAutocomplete,
+      mergeRequests: this.enableAutocomplete && !this.glFeatures.tributeAutocomplete,
       epics: this.enableAutocomplete,
       milestones: this.enableAutocomplete,
       labels: this.enableAutocomplete && !this.glFeatures.tributeAutocomplete,
diff --git a/app/views/shared/issuable/_close_reopen_report_toggle.html.haml b/app/views/shared/issuable/_close_reopen_report_toggle.html.haml
index abf5f58699f1c9a4f6357716c5424a5f380ba022..4c7aee094069414776970960f8cf8f79452010fd 100644
--- a/app/views/shared/issuable/_close_reopen_report_toggle.html.haml
+++ b/app/views/shared/issuable/_close_reopen_report_toggle.html.haml
@@ -39,10 +39,8 @@
 
       %li.divider.droplab-item-ignore
 
-      %li.report-item{ data: { text: _('Report abuse'), url: new_abuse_report_path(user_id: issuable.author.id, ref_url: issuable_url(issuable)),
-                       button_class: "#{button_class} btn-close-color", toggle_class: "#{toggle_class} btn-close-color", method: '' } }
-        %button.btn.btn-transparent
-          = icon('check', class: 'icon')
+      %li.report-item{ data: { text: _('Report abuse'), button_class: "#{button_class} btn-close-color", toggle_class: "#{toggle_class} btn-close-color", method: '' } }
+        %a.report-abuse-link{ :href =>  new_abuse_report_path(user_id: issuable.author.id, ref_url: issuable_url(issuable)) }
           .description
             %strong.title= _('Report abuse')
             %p.text
diff --git a/changelogs/unreleased/ss-fix-report-abuse-button.yml b/changelogs/unreleased/ss-fix-report-abuse-button.yml
new file mode 100644
index 0000000000000000000000000000000000000000..c7a88dd8712fe339fa1e5753a8b32c2a098fc6b7
--- /dev/null
+++ b/changelogs/unreleased/ss-fix-report-abuse-button.yml
@@ -0,0 +1,5 @@
+---
+title: Fix report abuse button in issues and mrs
+merge_request: 40918
+author:
+type: fixed
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 7e39ae616ec88d66b9a50dc604b37d67c3c080e8..b9ff1d35739064eaccf7321cc00d5b55752885bc 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -238,12 +238,13 @@ this, replace value of the `POSTGRESQL_SERVER_ADDRESS` with corresponding IP or
 address of the PgBouncer instance.
 
 This documentation doesn't provide PgBouncer installation instructions,
-you can:
+but you can:
 
 - Find instructions on the [official website](https://www.pgbouncer.org/install.html).
 - Use a [Docker image](https://hub.docker.com/r/edoburu/pgbouncer/).
 
-In addition to base PgBouncer configuration options, set the following values:
+In addition to the base PgBouncer configuration options, set the following values in
+your `pgbouncer.ini` file:
 
 - The [Praefect PostgreSQL database](#postgresql) in the `[databases]` section:
 
diff --git a/doc/development/telemetry/snowplow.md b/doc/development/telemetry/snowplow.md
index f01c2ec95c34af362b3783af9f17ffc8227ecb61..18257c5ac44db381fa3b72753cd494609cb27e57 100644
--- a/doc/development/telemetry/snowplow.md
+++ b/doc/development/telemetry/snowplow.md
@@ -316,6 +316,11 @@ There are several tools for developing and testing Snowplow Event
 
 **{check-circle}** Available, **{status_preparing}** In progress, **{dotted-circle}** Not Planned
 
+### Preparing your MR for Review
+
+1. For frontend events, in the MR description section, add a screenshot of the event's relevant section using the [Snowplow Analytics Debugger](https://chrome.google.com/webstore/detail/snowplow-analytics-debugg/jbnlcgeengmijcghameodeaenefieedm) Chrome browser extension.
+1. For backend events, please use Snowplow Micro and add the output of the Snowplow Micro good events  `GET http://localhost:9090/micro/good`.
+
 ### Snowplow Analytics Debugger Chrome Extension
 
 Snowplow Analytics Debugger is a browser extension for testing frontend events. This works on production, staging and local development environments.
diff --git a/doc/operations/metrics/dashboards/variables.md b/doc/operations/metrics/dashboards/variables.md
index 8b0d7f370521ab438a46d93e998e584563ad2fd5..22c8814e8bd63af6085cb7e69b8c7af1994a4b5a 100644
--- a/doc/operations/metrics/dashboards/variables.md
+++ b/doc/operations/metrics/dashboards/variables.md
@@ -18,6 +18,7 @@ Queries that continue to use the old format will show no data.
 
 GitLab supports a limited set of [CI variables](../../../ci/variables/README.md) in the Prometheus query. This is particularly useful for identifying a specific environment, for example with `ci_environment_slug`. The supported variables are:
 
+- `environment_filter`
 - `ci_environment_slug`
 - `kube_namespace`
 - `ci_project_name`
@@ -29,6 +30,14 @@ GitLab supports a limited set of [CI variables](../../../ci/variables/README.md)
 NOTE: **Note:**
 Variables for Prometheus queries must be lowercase.
 
+### environment_filter
+
+`environment_filter` is automatically expanded to `container_name!="POD",environment="ENVIRONMENT_NAME"`
+where `ENVIRONMENT_NAME` is the name of the current environment.
+
+For example, a Prometheus query like `container_memory_usage_bytes{ {{environment_filter}} }`
+becomes `container_memory_usage_bytes{ container_name!="POD",environment="production" }`.
+
 ### __range
 
 The `__range` variable is useful in Prometheus
diff --git a/doc/user/application_security/api_fuzzing/index.md b/doc/user/application_security/api_fuzzing/index.md
new file mode 100644
index 0000000000000000000000000000000000000000..2a9c0910a13211459a7992a33df5c4fcd5816cb0
--- /dev/null
+++ b/doc/user/application_security/api_fuzzing/index.md
@@ -0,0 +1,739 @@
+---
+stage: Secure
+group: Fuzz Testing
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+type: reference, howto
+---
+
+# Web API Fuzz Testing **(ULTIMATE)**
+
+You can add web API fuzzing to your [GitLab CI/CD](../../../ci/README.md)
+pipelines. This helps you discover bugs and potential security issues that other QA processes may miss. 
+API fuzzing performs fuzz testing of API operation parameters. 
+Fuzz testing sets operation parameters to unexpected values in an effort to cause unexpected behavior and errors in the API backend.
+
+We recommend that you use fuzz testing in addition to [GitLab Secure](../index.md)'s
+other security scanners and your own test processes. If you're using [GitLab CI/CD](../../../ci/README.md),
+you can run fuzz tests as part your CI/CD workflow.
+
+## Requirements
+
+- One of the following web API types:
+  - REST API
+  - SOAP
+  - GraphQL
+  - Form bodies, JSON, or XML
+- An OpenAPI definition, or HTTP Archive (HAR) of requests to test
+
+## When fuzzing scans run
+
+When using the `API-Fuzzing.gitlab-ci.yml` template, the `fuzz` job runs last, as shown here. To
+ensure API fuzzing scans the latest code, your CI pipeline should deploy changes to a test
+environment in one of the jobs preceding the `fuzz` job:
+
+```yaml
+stages:
+  - build
+  - test
+  - deploy
+  - fuzz
+```
+
+Note that if your pipeline is configured to deploy to the same web server on each run, running a
+pipeline while another is still running could cause a race condition in which one pipeline
+overwrites the code from another. The API to scan should be excluded from changes for the duration
+of a fuzzing scan. The only changes to the API should be from the fuzzing scanner. Be aware that
+any changes made to the API (for example, by users, scheduled tasks, database changes, code
+changes, other pipelines, or other scanners) during a scan could cause inaccurate results.
+
+## Configuration
+
+There are two ways to perform scans. See the configuration section for the one you wish to use:
+
+- [OpenAPI v2 specification](#openapi-specification)
+- [HTTP Archive (HAR)](#http-archive-har)
+
+Examples of both configurations can be found here:
+
+- [Example OpenAPI v2 specification project](https://gitlab.com/gitlab-org/security-products/demos/api-fuzzing-example/-/tree/openapi)
+- [Example HTTP Archive (HAR) project](https://gitlab.com/gitlab-org/security-products/demos/api-fuzzing-example/-/tree/har)
+
+### OpenAPI Specification
+
+The [OpenAPI Specification](https://www.openapis.org/) (formerly the Swagger Specification) is an
+API description format for REST APIs. This section shows you how to configure API fuzzing by using
+an OpenAPI specification to provide information about the target API to test. OpenAPI specifications
+are provided as a filesystem resource or URL.
+
+Follow these steps to configure API fuzzing in GitLab with an OpenAPI specification:
+
+1. To use API fuzzing, you must [include](../../../ci/yaml/README.md#includetemplate)
+   the [`API-Fuzzing.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/API-Fuzzing.gitlab-ci.yml)
+   that's provided as part of your GitLab installation. To do so, add the following to your
+   `.gitlab-ci.yml` file:
+
+   ```yaml
+   include:
+     - template: API-Fuzzing.gitlab-ci.yml
+   ```
+
+1. Add the configuration file [`gitlab-api-fuzzing-config.yml`](https://gitlab.com/gitlab-org/security-products/analyzers/api-fuzzing/-/blob/master/gitlab-api-fuzzing-config.yml) to your repository's root as `.gitlab-api-fuzzing.yml`.
+
+1. The [configuration file](#configuration-files) has several testing profiles defined with varying
+   amounts of fuzzing. We recommend that you start with the `Quick-10` profile. Testing with this
+   profile completes quickly, allowing for easier configuration validation.
+
+   Provide the profile by adding the `FUZZAPI_PROFILE` variable to your `.gitlab-ci.yml` file,
+   substituting `Quick-10` for the profile you choose:
+
+   ```yaml
+   include:
+     - template: API-Fuzzing.gitlab-ci.yml
+
+   variables:
+     FUZZAPI_PROFILE: Quick-10
+   ```
+
+1. Provide the location of the OpenAPI v2 specification. You can provide the specification as a file
+   or URL. Specify the location by adding the `FUZZAPI_OPENAPI` variable:
+
+   ```yaml
+   include:
+     - template: API-Fuzzing.gitlab-ci.yml
+
+   variables:
+     FUZZAPI_PROFILE: Quick-10
+     FUZZAPI_OPENAPI: test-api-specification.json
+   ```
+
+1. The target API instance's base URL is also required. Provide it by using the `FUZZAPI_TARGET_URL`
+   variable:
+
+   ```yaml
+   include:
+     - template: API-Fuzzing.gitlab-ci.yml
+
+   variables:
+     FUZZAPI_PROFILE: Quick-10
+     FUZZAPI_OPENAPI: test-api-specification.json
+     FUZZAPI_TARGET_URL: http://test-deployment/
+   ```
+
+This is a minimal configuration for API Fuzzing. From here you can:
+
+- [Run your first scan](#running-your-first-scan).
+- [Add authentication](#authentication).
+- Learn how to [handle false positives](#handling-false-positives).
+
+DANGER: **Danger:**
+**NEVER** run fuzz testing against a production server. Not only can it perform *any* function that
+the API can, it may also trigger bugs in the API. This includes actions like modifying and deleting
+data. Only run fuzzing against a test server.
+
+### HTTP Archive (HAR)
+
+The [HTTP Archive format (HAR)](http://www.softwareishard.com/blog/har-12-spec/)
+is an archive file format for logging HTTP transactions. When used with GitLab's API fuzzer, HAR
+must contain records of calling the web API to test. The API fuzzer extracts all the requests and
+uses them to perform testing.
+
+You can use various tools to generate HAR files:
+
+- [Fiddler](https://www.telerik.com/fiddler): Web debugging proxy
+- [Insomnia Core](https://insomnia.rest/): API client
+- [Chrome](https://www.google.com/chrome): Browser
+- [Firefox](https://www.mozilla.org/en-US/firefox/): Browser
+
+DANGER: **Warning:**
+HAR files may contain sensitive information such as authentication tokens, API keys, and session
+cookies. We recommend that you review the HAR file contents before adding them to a repository.
+
+Follow these steps to configure API fuzzing to use a HAR file that provides information about the
+target API to test:
+
+1. To use API fuzzing, you must [include](../../../ci/yaml/README.md#includetemplate)
+   the [`API-Fuzzing.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/API-Fuzzing.gitlab-ci.yml)
+   that's provided as part of your GitLab installation. To do so, add the following to your
+   `.gitlab-ci.yml` file:
+
+   ```yaml
+   include:
+     - template: API-Fuzzing.gitlab-ci.yml
+   ```
+
+1. Add the configuration file [`gitlab-api-fuzzing-config.yml`](https://gitlab.com/gitlab-org/security-products/analyzers/api-fuzzing/-/blob/master/gitlab-api-fuzzing-config.yml) to your repository's root as `.gitlab-api-fuzzing.yml`.
+
+1. The [configuration file](#configuration-files) has several testing profiles defined with varying
+   amounts of fuzzing. We recommend that you start with the `Quick-10` profile. Testing with this
+   profile completes quickly, allowing for easier configuration validation.
+
+   Provide the profile by adding the `FUZZAPI_PROFILE` variable to your `.gitlab-ci.yml` file,
+   substituting `Quick-10` for the profile you choose:
+
+   ```yaml
+   include:
+     - template: API-Fuzzing.gitlab-ci.yml
+
+   variables:
+     FUZZAPI_PROFILE: Quick-10
+   ```
+
+1. Add the `FUZZAPI_HAR` variable and set it to the HAR file's location:
+
+   ```yaml
+   include:
+     - template: API-Fuzzing.gitlab-ci.yml
+
+   variables:
+     FUZZAPI_PROFILE: Quick-10
+     FUZZAPI_HAR: test-api-specification.json
+   ```
+
+1. Add the `FUZZAPI_TARGET_URL` variable and set it to the target API instance's base URL:
+
+   ```yaml
+   include:
+     - template: API-Fuzzing.gitlab-ci.yml
+
+   variables:
+     FUZZAPI_PROFILE: Quick-10
+     FUZZAPI_HAR: test-api-specification.json
+     FUZZAPI_TARGET_URL: http://test-deployment/
+   ```
+
+This is a minimal configuration for API Fuzzing. From here you can:
+
+- [Run your first scan](#running-your-first-scan).
+- [Add authentication](#authentication).
+- Learn how to [handle false positives](#handling-false-positives).
+
+DANGER: **Danger:**
+**NEVER** run fuzz testing against a production server. Not only can it perform *any* function that
+the API can, it may also trigger bugs in the API. This includes actions like modifying and deleting
+data. Only run fuzzing against a test server.
+
+### Authentication
+
+Authentication is handled by providing the authentication token as a header or cookie. You can
+provide a script that performs an authentication flow or calculates the token.
+
+#### HTTP Basic Authentication
+
+[HTTP basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication)
+works by setting the `Authorization` header with the Base64-encoded username and password. The
+resulting header looks like this:
+
+```http
+Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
+```
+
+To have API fuzzing include this header during a scan, set an overrides environment variable.
+Base64-encode your username and password, separated with a `:` (for example, `username:password`).
+
+On Linux, create a text file with the username and password separated by `:`. Make sure the file has
+a single line with no return at the end. Then use the command line tool `base64` to encode it.
+
+```shell
+$ base64 ~/test.txt
+dXNlcm5hbWU6cGFzc3dvcmQ=
+```
+
+The output `dXNlcm5hbWU6cGFzc3dvcmQ=` is the Base64-encoded credentials. 
+
+DANGER: **Warning:**
+Base64 is **not** encryption. This string can be easily decoded and should not be considered a safe
+way to protect or store credentials.
+
+[Next create a CI/CD variable](../../../ci/variables/README.md#create-a-custom-variable-in-the-ui),
+for example `TEST_API_BASICAUTH`, with the value
+`{"headers":{"Authorization":"Basic dXNlcm5hbWU6cGFzc3dvcmQ="}}` (substitute your Base64-encoded
+credential string). You can create CI/CD variables from the GitLab projects page at
+**Settings > CI/CD** in the **Variables** section.
+
+Set `FUZZAPI_OVERRIDES_ENV` in your `.gitlab-ci.yml` file:
+
+```yaml
+include:
+  - template: API-Fuzzing.gitlab-ci.yml
+
+variables:
+  FUZZAPI_PROFILE: Quick
+  FUZZAPI_OPENAPI: test-api-specification.json
+  FUZZAPI_TARGET_URL: http://test-deployment/
+  FUZZAPI_OVERRIDES_ENV: $TEST_API_BASICAUTH
+```
+
+#### Bearer Tokens
+
+Bearer tokens are used by several different authentication mechanisms, including OAuth2 and JSON Web
+Tokens (JWT). Bearer tokens are transmitted using the `Authorization` HTTP header. To use bearer
+tokens with API fuzzing, you need one of the following:
+
+- A token that doesn't expire
+- A way to generate a token that lasts the length of testing
+- A Python script that API fuzzing can call to generate the token
+
+##### Token doesn't expire
+
+If the bearer token doesn't expire, you can provide it using the `FUZZAPI_OVERRIDES_ENV` variable.
+The `FUZZAPI_OVERRIDES_ENV` content is a JSON snippet that provides headers and cookies that should
+be added to outgoing HTTP requests made by API fuzzing.
+
+Create a CI/CD variable, for example `TEST_API_BEARERAUTH`, with the value
+`{"headers":{"Authorization":"Bearer dXNlcm5hbWU6cGFzc3dvcmQ="}}` (substitute your token). You can
+create CI/CD variables from the GitLab projects page at **Settings > CI/CD** in the **Variables**
+section.
+
+Set `FUZZAPI_OVERRIDES_ENV` in your `.gitlab-ci.yml` file:
+
+```yaml
+include:
+  - template: API-Fuzzing.gitlab-ci.yml
+
+variables:
+  FUZZAPI_PROFILE: Quick-10
+  FUZZAPI_OPENAPI: test-api-specification.json
+  FUZZAPI_TARGET_URL: http://test-deployment/
+  FUZZAPI_OVERRIDES_ENV: $TEST_API_BEARERAUTH
+```
+
+To validate that authentication is working, run an API fuzzing test and review the fuzzing logs and
+the test API's application logs.
+
+##### Token generated at test-runtime
+
+If the bearer token must be generated, and the resulting token doesn't expire during testing, you
+can provide to API fuzzing a file containing the token. This file can be generated by a prior stage
+and job, or as part of the API fuzzing job.
+
+API fuzzing expects to receive a JSON file with the following structure:
+
+```json
+{
+  "headers" : {
+    "Authorization" : "Bearer dXNlcm5hbWU6cGFzc3dvcmQ="
+  }
+}
+```
+
+This file can be generated by a prior stage and provided to API fuzzing through the
+`FUZZAPI_OVERRIDES_FILE` variable.
+
+Set `FUZZAPI_OVERRIDES_FILE` in your `.gitlab-ci.yml` file:
+
+```yaml
+include:
+  - template: API-Fuzzing.gitlab-ci.yml
+
+variables:
+  FUZZAPI_PROFILE: Quick
+  FUZZAPI_OPENAPI: test-api-specification.json
+  FUZZAPI_TARGET_URL: http://test-deployment/
+  FUZZAPI_OVERRIDES_FILE: output/api-fuzzing-overrides.json
+```
+
+To validate that authentication is working, run an API fuzzing test and review the fuzzing logs and
+the test API's application logs.
+
+##### Token has short expiration
+
+If the bearer token must be generated and expires prior to the scan's completion, you can provide a
+program or script for the API fuzzer to execute on a provided interval. The provided script runs in
+an Alpine Linux container that has Python 3 and Bash installed. If the Python script requires
+additional packages, it must detect this and install the packages at runtime.
+
+The script must create a JSON file containing the bearer token in a specific format:
+
+```json
+{
+  "headers" : {
+    "Authorization" : "Bearer dXNlcm5hbWU6cGFzc3dvcmQ="
+  }
+}
+```
+
+You must provide three variables, each set for correct operation:
+
+- `FUZZAPI_OVERRIDES_FILE`: File generated by the provided command.
+- `FUZZAPI_OVERRIDES_CMD`: Command to generate JSON file.
+- `FUZZAPI_OVERRIDES_INTERVAL`: Interval in seconds to run command.
+
+```yaml
+include:
+  - template: API-Fuzzing.gitlab-ci.yml
+
+variables:
+  FUZZAPI_PROFILE: Quick-10
+  FUZZAPI_OPENAPI: test-api-specification.json
+  FUZZAPI_TARGET_URL: http://test-deployment/
+  FUZZAPI_OVERRIDES_FILE: output/api-fuzzing-overrides.json
+  FUZZAPI_OVERRIDES_CMD: renew_token.py
+  FUZZAPI_OVERRIDES_INTERVAL: 300
+```
+
+To validate that authentication is working, run an API fuzzing test and review the fuzzing logs and
+the test API's application logs.
+
+### Configuration files
+
+To get started quickly, GitLab provides you with the configuration file
+[`gitlab-api-fuzzing-config.yml`](https://gitlab.com/gitlab-org/security-products/analyzers/api-fuzzing/-/blob/master/gitlab-api-fuzzing-config.yml).
+This file has several testing profiles that perform various amounts of testing. The run time of each
+increases as the numbers go up. To use a configuration file, add it to your repository's root as
+`.gitlab-api-fuzzing.yml`.
+
+| Profile  | Scan Type  |
+|:---------|:-----------|
+|Quick-10  |Fuzzing 10 times per parameter  |
+|Medium-20 |Fuzzing 20 times per parameter  |
+|Medium-50 |Fuzzing 50 times per parameter  |
+|Long-100  |Fuzzing 100 times per parameter |
+
+### Available variables
+
+| Environment variable        | Description        |
+|-----------------------------|--------------------|
+| `FUZZAPI_VERSION`           |Specify API Fuzzing container version. Defaults to `latest`. |
+| `FUZZAPI_TARGET_URL`        |Base URL of API testing target. |
+|[`FUZZAPI_CONFIG`](#configuration-files)|API Fuzzing configuration file. Defaults to `.gitlab-apifuzzer.yml`. |
+|[`FUZZAPI_PROFILE`](#configuration-files)|Configuration profile to use during testing. Defaults to `Quick`. |
+| `FUZZAPI_REPORT`            |Scan report filename. Defaults to `gl-api_fuzzing-report.xml`. |
+|[`FUZZAPI_OPENAPI`](#openapi-specification)|OpenAPI specification file or URL. |
+|[`FUZZAPI_HAR`](#http-archive-har)|HTTP Archive (HAR) file. |
+|[`FUZZAPI_OVERRIDES_FILE`](#overrides)     |Path to a JSON file containing overrides. |
+|[`FUZZAPI_OVERRIDES_ENV`](#overrides)      |JSON string containing headers to override. |
+|[`FUZZAPI_OVERRIDES_CMD`](#overrides)      |Overrides command. |
+|[`FUZZAPI_OVERRIDES_INTERVAL`](#overrides) |How often to run overrides command in seconds. Defaults to `0` (once). |
+
+<!--|[`FUZZAPI_D_TARGET_IMAGE`](#target-container) |API target docker image |
+|[`FUZZAPI_D_TARGET_ENV`](#target-container)   |Docker environment options |
+|[`FUZZAPI_D_TARGET_VOLUME`](#target-container)|Docker volume options |
+|[`FUZZAPI_D_TARGET_PORTS`](#target-container) |Docker port options |
+| `FUZZAPI_D_WORKER_IMAGE`    |Custom worker docker image |
+| `FUZZAPI_D_WORKER_ENV`      |Custom worker docker environment options |
+| `FUZZAPI_D_WORKER_VOLUME`   |Custom worker docker volume options |
+| `FUZZAPI_D_WORKER_PORTS`    |Custom worker docker port options |
+| `FUZZAPI_D_NETWORK`         |Name of docker network, defaults to "testing-net"|
+| `FUZZAPI_D_PRE_SCRIPT`      |Pre script runs after docker login and docker network create, but before starting the scanning image container.|
+| `FUZZAPI_D_POST_SCRIPT`     |Post script runs after scanning image container is started. This is the place to start your target(s) and kick off scanning when using an advanced configuration.| -->
+
+### Overrides
+
+API Fuzzing provides a method to add or override headers and cookies for all outbound HTTP requests
+made. You can use this to inject semver headers, authentication, and so on. The
+[authentication section](#authentication) includes examples of using overrides for that purpose.
+
+Overrides uses a JSON document to define the headers and cookies:
+
+```json
+{
+  "headers": {
+    "header1": "value",
+    "header2": "value"
+  },
+  "cookies": {
+    "cookie1": "value",
+    "cookie2": "value"
+  }
+}
+```
+
+Example usage for setting a single header:
+
+```json
+{
+  "headers": {
+    "Authorization": "Bearer dXNlcm5hbWU6cGFzc3dvcmQ=" 
+  }
+}
+```
+
+Example usage for setting both a header and cookie:
+
+```json
+{
+  "headers": {
+    "Authorization": "Bearer dXNlcm5hbWU6cGFzc3dvcmQ=" 
+  },
+  "cookies": {
+    "flags": "677"
+  }
+}
+```
+
+You can provide this JSON document as a file or environment variable. You may also provide a command
+to generate the JSON document. The command can run at intervals to support values that expire.
+
+#### Using a file
+
+To provide the overrides JSON as a file, the `FUZZAPI_OVERRIDES_FILE` environment variable is set. The path is relative to the job current working directory.
+
+Example `.gitlab-ci.yml`:
+
+```yaml
+include:
+  - template: API-Fuzzing.gitlab-ci.yml
+
+variables:
+  FUZZAPI_PROFILE: Quick
+  FUZZAPI_OPENAPI: test-api-specification.json
+  FUZZAPI_TARGET_URL: http://test-deployment/
+  FUZZAPI_OVERRIDES_FILE: output/api-fuzzing-overrides.json
+```
+
+#### Using an environment variable
+
+To provide the overrides JSON as an environment variable, use the `FUZZAPI_OVERRIDES_ENV` variable.
+This allows you to place the JSON as CI/CD variables that can be masked and protected.
+
+In this example `.gitlab-ci.yml`, the JSON is provided directly:
+
+```yaml
+include:
+  - template: API-Fuzzing.gitlab-ci.yml
+
+variables:
+  FUZZAPI_PROFILE: Quick
+  FUZZAPI_OPENAPI: test-api-specification.json
+  FUZZAPI_TARGET_URL: http://test-deployment/
+  FUZZAPI_OVERRIDES_ENV: '{"headers":{"X-API-Version":"2"}}'
+```
+
+In this example `.gitlab-ci.yml`, the CI/CD variable `SECRET_OVERRIDES` provides the JSON. This is a
+[group or instance level environment variable defined in the UI](../../../ci/variables/README.md#instance-level-cicd-environment-variables):
+
+```yaml
+include:
+  - template: API-Fuzzing.gitlab-ci.yml
+
+variables:
+  FUZZAPI_PROFILE: Quick
+  FUZZAPI_OPENAPI: test-api-specification.json
+  FUZZAPI_TARGET_URL: http://test-deployment/
+  FUZZAPI_OVERRIDES_ENV: $SECRET_OVERRIDES
+```
+
+#### Using a command
+
+If the value must be generated or regenerated on expiration, you can provide a program or script for
+the API fuzzer to execute on a specified interval. The provided script runs in an Alpine Linux
+container that has Python 3 and Bash installed. If the Python script requires additional packages,
+it must detect this and install the packages at runtime. The script creates the overrides JSON file
+as defined above.
+
+You must provide three variables, each set for correct operation:
+
+- `FUZZAPI_OVERRIDES_FILE`: File generated by the provided command.
+- `FUZZAPI_OVERRIDES_CMD`: Command to generate JSON file.
+- `FUZZAPI_OVERRIDES_INTERVAL`: Interval in seconds to run command.
+
+```yaml
+include:
+  - template: API-Fuzzing.gitlab-ci.yml
+
+variables:
+  FUZZAPI_PROFILE: Quick
+  FUZZAPI_OPENAPI: test-api-specification.json
+  FUZZAPI_TARGET_URL: http://test-deployment/
+  FUZZAPI_OVERRIDES_FILE: output/api-fuzzing-overrides.json
+  FUZZAPI_OVERRIDES_CMD: renew_token.py
+  FUZZAPI_OVERRIDES_INTERVAL: 300
+```
+
+## Running your first scan
+
+When configured correctly, a CI/CD pipeline contains a `Fuzz` stage and a `apifuzzer_fuzz` job. The
+job only fails when an invalid configuration is provided. During normal operation, the job always
+succeeds even if faults are identified during fuzz testing.
+
+Faults are displayed on the **Tests** pipeline tab with the suite name **API-Fuzzing**. The **Name**
+field on the **Tests** page includes the fuzz-tested operation and parameter. The **Trace** field
+contains a writeup of the identified fault. This writeup contains information on what the fuzzer
+tested and how it detected something wrong.
+
+To prevent an excessive number of reported faults, the API fuzzing scanner limits the number of
+faults it reports to one per parameter.
+
+### Fault Writeup
+
+The faults that API fuzzing finds aren't associated with a specific vulnerability type. They require
+investigation to determine what type of issue they are and if they should be fixed. See
+[handling false positives](#handling-false-positives) for information about configuration changes
+you can make to limit the number of false positives reported.
+
+This table contains a description of fields in an API fuzzing fault writeup.
+
+| Writeup Item | Description |
+|:-------------|:------------|
+| Operation | The operation tested. |
+| Parameter | The field modified. This can be a path segment, header, query string, or body element. |
+| Endpoint  | The endpoint being tested. |
+| Check     | Check module producing the test. Checks can be turned on and off. |
+| Assert    | Assert module that detected a failure. Assertions can be configured and turned on and off. |
+| CWE       | Fuzzing faults always have the same CWE. |
+| OWASP     | Fuzzing faults always have the same OWASP ID. |
+| Exploitability | Fuzzing faults always have an `unknown` exploitability. |
+| Impact         | Fuzzing faults always have an `unknown` risk impact. |
+| Description    | Verbose description of what the check did. Includes the original parameter value and the modified (mutated) value. |
+| Detection      | Why a failure was detected and reported. This is related to the Assert that was used. |
+| Original Request  | The original, unmodified HTTP request. Useful when reviewing the actual request to see what changes were made. |
+| Actual Request    | The request that produced the failure. This request has been modified in some way by the Check logic. |
+| Actual Response   | The response to the actual request. |
+| Recorded Request  | An unmodified request. |
+| Recorded Response | The response to the unmodified request. You can compare this with the actual request when triaging this fault. |
+
+## Handling False Positives
+
+False positives can be handled in two ways:
+
+- Turn off the Check producing the false positive. This prevents the check from generating any
+  faults. Example checks are the JSON Fuzzing Check, and Form Body Fuzzing Check.
+- Fuzzing checks have several methods of detecting when a fault is identified, called _Asserts_.
+  Asserts can also be turned off and configured. For example, the API fuzzer by default uses HTTP
+  status codes to help identify when something is a real issue. If an API returns a 500 error during
+  testing, this creates a fault. This isn't always desired, as some frameworks return 500 errors
+  often.
+
+### Turn off a Check
+
+Checks perform testing of a specific type and can be turned on and off for specific configuration
+profiles. The provided [configuration files](#configuration-files) define several profiles that you
+can use. The profile definition in the configuration file lists all the checks that are active
+during a scan. To turn off a specific check, simply remove it from the profile definition in the
+configuration file. The profiles are defined in the `Profiles` section of the configuration file.
+
+Example profile definition:
+
+```yaml
+Profiles:
+- Name: Quick-10
+  DefaultProfile: Quick
+  Routes:
+  - Route: *Route0
+    Checks:
+    - Name: FormBodyFuzzingCheck
+      Configuration:
+        FuzzingCount: 10
+        UnicodeFuzzing: true
+    - Name: GeneralFuzzingCheck
+      Configuration:
+        FuzzingCount: 10
+        UnicodeFuzzing: true
+    - Name: JsonFuzzingCheck
+      Configuration:
+        FuzzingCount: 10
+        UnicodeFuzzing: true
+    - Name: XmlFuzzingCheck
+      Configuration:
+        FuzzingCount: 10
+        UnicodeFuzzing: true
+```
+
+To turn off the General Fuzzing Check you can remove these lines:
+
+```yaml
+    - Name: GeneralFuzzingCheck
+      Configuration:
+        FuzzingCount: 10
+        UnicodeFuzzing: true
+```
+
+This results in the following YAML:
+
+```yaml
+- Name: Quick-10
+  DefaultProfile: Quick
+  Routes:
+  - Route: *Route0
+    Checks:
+    - Name: FormBodyFuzzingCheck
+      Configuration:
+        FuzzingCount: 10
+        UnicodeFuzzing: true
+    - Name: JsonFuzzingCheck
+      Configuration:
+        FuzzingCount: 10
+        UnicodeFuzzing: true
+    - Name: XmlFuzzingCheck
+      Configuration:
+        FuzzingCount: 10
+        UnicodeFuzzing: true
+```
+
+### Turn off an Assertion for a Check
+
+Assertions detect faults in tests produced by checks. Many checks support multiple Assertions such
+as Log Analysis, Response Analysis, and Status Code. When a fault is found, the Assertion used is
+provided. To identify which Assertions are on by default, see the Checks default configuration in
+the configuration file. The section is called `Checks`.
+
+This example shows the FormBody Fuzzing Check:
+
+```yaml
+Checks:
+- Name: FormBodyFuzzingCheck
+  Configuration:
+    FuzzingCount: 30
+    UnicodeFuzzing: true
+  Assertions:
+  - Name: LogAnalysisAssertion
+  - Name: ResponseAnalysisAssertion
+  - Name: StatusCodeAssertion
+```
+
+Here you can see three Assertions are on by default. A common source of false positives is
+`StatusCodeAssertion`. To turn it off, modify its configuration in the `Profiles` section. This
+example provides only the other two Assertions (`LogAnalysisAssertion`,
+`ResponseAnalysisAssertion`). This prevents `FormBodyFuzzingCheck` from using `StatusCodeAssertion`:
+
+```yaml
+Profiles:
+- Name: Quick-10
+  DefaultProfile: Quick
+  Routes:
+  - Route: *Route0
+    Checks:
+    - Name: FormBodyFuzzingCheck
+      Configuration:
+        FuzzingCount: 10
+        UnicodeFuzzing: true
+      Assertions:
+      - Name: LogAnalysisAssertion
+      - Name: ResponseAnalysisAssertion
+    - Name: GeneralFuzzingCheck
+      Configuration:
+        FuzzingCount: 10
+        UnicodeFuzzing: true
+    - Name: JsonFuzzingCheck
+      Configuration:
+        FuzzingCount: 10
+        UnicodeFuzzing: true
+    - Name: XmlInjectionCheck
+      Configuration:
+        FuzzingCount: 10
+        UnicodeFuzzing: true
+```
+
+<!--
+### Target Container
+
+The API Fuzzing template supports launching a docker container containing an API target using docker-in-docker.
+
+TODO
+-->
+
+## Glossary
+
+- Assert: Assertions are detection modules used by checks to trigger a fault. Many assertions have
+  configurations. A check can use multiple Assertions. For example, Log Analysis, Response Analysis,
+  and Status Code are common Assertions used together by checks. Checks with multiple Assertions
+  allow them to be turned on and off.
+- Check: Performs a specific type of test, or performed a check for a type of vulnerability. For
+  example, the JSON Fuzzing Check performs fuzz testing of JSON payloads. The API fuzzer is
+  comprised of several checks. Checks can be turned on and off in a profile.
+- Fault: During fuzzing, a failure identified by an Assert is called a fault. Faults are
+  investigated to determine if they are a security vulnerability, a non-security issue, or a false
+  positive. Faults don't have a known vulnerability type until they are investigated. Example
+  vulnerability types are SQL Injection and Denial of Service.
+- Profile: A configuration file has one or more testing profiles, or sub-configurations. You may
+  have a profile for feature branches and another with extra testing for a main branch.
diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md
index 14f44a0476017a8f0884c69e3aa341d55274d26f..7d0b14a83264eeeb2ddcb1d0f2282d5163e9f07c 100644
--- a/doc/user/application_security/index.md
+++ b/doc/user/application_security/index.md
@@ -67,6 +67,7 @@ GitLab uses the following tools to scan and report known vulnerabilities found i
 | [Dependency List](dependency_list/index.md) **(ULTIMATE)**                   | View your project's dependencies and their known vulnerabilities.      |
 | [Dependency Scanning](dependency_scanning/index.md) **(ULTIMATE)**           | Analyze your dependencies for known vulnerabilities.                   |
 | [Dynamic Application Security Testing (DAST)](dast/index.md) **(ULTIMATE)**  | Analyze running web applications for known vulnerabilities.            |
+| [API fuzzing](api_fuzzing/index.md) **(ULTIMATE)**                 | Find unknown bugs and vulnerabilities in web APIs with fuzzing.    |
 | [Secret Detection](secret_detection/index.md) **(ULTIMATE)**                 | Analyze Git history for leaked secrets.                                |
 | [Security Dashboard](security_dashboard/index.md) **(ULTIMATE)**             | View vulnerabilities in all your projects and groups.                  |
 | [Static Application Security Testing (SAST)](sast/index.md)                  | Analyze source code for known vulnerabilities.                         |
diff --git a/doc/user/packages/composer_repository/index.md b/doc/user/packages/composer_repository/index.md
index 54e7c4e56bece60957a27269e029733f100d9723..2d974a6321f29d7fb38b55931d4b5a01111f8fd0 100644
--- a/doc/user/packages/composer_repository/index.md
+++ b/doc/user/packages/composer_repository/index.md
@@ -79,16 +79,17 @@ git push origin v1.0.0
 Now that the basics of our project is completed, we can publish the package.
 To publish the package, you need:
 
-- A personal access token. You can generate a [personal access token](../../../user/profile/personal_access_tokens.md) with the scope set to `api` for repository authentication.
-   NOTE: **Note:**
+- A personal access token or `CI_JOB_TOKEN`.
 
-  [Deploy tokens](./../../project/deploy_tokens/index.md) are not yet supported for use with Composer.
+  ([Deploy tokens](./../../project/deploy_tokens/index.md) are not yet supported for use with Composer.)
 
 - Your project ID which can be found on the home page of your project.
 
 To publish the package hosted on GitLab, make a `POST` request to the GitLab package API.
 A tool like `curl` can be used to make this request:
 
+You can generate a [personal access token](../../../user/profile/personal_access_tokens.md) with the scope set to `api` for repository authentication. For example:
+
 ```shell
 curl --data tag=<tag> 'https://__token__:<personal-access-token>@gitlab.com/api/v4/projects/<project_id>/packages/composer'
 ```
@@ -101,6 +102,21 @@ Where:
 
 If the above command succeeds, you now should be able to see the package under the **Packages & Registries** section of your project page.
 
+### Publishing the package with CI/CD
+
+To work with Composer commands within [GitLab CI/CD](./../../../ci/README.md), you can
+publish Composer packages by using `CI_JOB_TOKEN` in your `.gitlab-ci.yml` file:
+
+```yaml
+stages:
+  - deploy
+
+deploy:
+  stage: deploy
+  script:
+    - 'curl --header "Job-Token: $CI_JOB_TOKEN" --data tag=<tag> "https://gitlab.example.com/api/v4/projects/$CI_PROJECT_ID/packages/composer"'
+```
+
 ### Installing a package
 
 To install your package, you need:
diff --git a/doc/user/project/integrations/prometheus_library/nginx.md b/doc/user/project/integrations/prometheus_library/nginx.md
index eda6f64ccac23b82fde913f3338c7f6d114e92e0..0d3042463c90535e3581ef8aa7cc61618c78d7ab 100644
--- a/doc/user/project/integrations/prometheus_library/nginx.md
+++ b/doc/user/project/integrations/prometheus_library/nginx.md
@@ -18,6 +18,8 @@ The [Prometheus service](../prometheus.md) must be enabled.
 
 NGINX server metrics are detected, which tracks the pages and content directly served by NGINX.
 
+[`environment_filter`](../../../../operations/metrics/dashboards/variables.md#environment_filter) is one of the predefined variables that metrics dashboards support.
+
 | Name | Query |
 | ---- | ----- |
 | Throughput (req/sec) | `sum(rate(nginx_server_requests{server_zone!="*", server_zone!="_", %{environment_filter}}[2m])) by (code)` |
diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md
index a65e48d5d56b1e602b839cc1146c2962ab8223c4..f5be0881a295ae30dffb203924991b0a12cafe0e 100644
--- a/doc/user/project/settings/index.md
+++ b/doc/user/project/settings/index.md
@@ -37,6 +37,9 @@ You can select a framework label to identify that your project has certain compl
 - SOC 2 - Service Organization Control 2
 - SOX - Sarbanes-Oxley
 
+NOTE: **Note:**
+Compliance framework labels do not affect your project settings.
+
 ### Sharing and permissions
 
 For your repository, you can set up features such as public access, repository features,
diff --git a/lib/gitlab/error_tracking.rb b/lib/gitlab/error_tracking.rb
index 8d5611411c994add5016f00d4b9091b24c6a75fd..803acef9a40ec54eb25adff29de8ac4bd57b7a0b 100644
--- a/lib/gitlab/error_tracking.rb
+++ b/lib/gitlab/error_tracking.rb
@@ -26,6 +26,8 @@ module Gitlab
           # Sanitize fields based on those sanitized from Rails.
           config.sanitize_fields = Rails.application.config.filter_parameters.map(&:to_s)
           config.processors << ::Gitlab::ErrorTracking::Processor::SidekiqProcessor
+          config.processors << ::Gitlab::ErrorTracking::Processor::GrpcErrorProcessor
+
           # Sanitize authentication headers
           config.sanitize_http_headers = %w[Authorization Private-Token]
           config.tags = extra_tags_from_env.merge(program: Gitlab.process_name)
diff --git a/lib/gitlab/error_tracking/processor/grpc_error_processor.rb b/lib/gitlab/error_tracking/processor/grpc_error_processor.rb
new file mode 100644
index 0000000000000000000000000000000000000000..a19e066a660941e06b5604879d04bab7d4f3381e
--- /dev/null
+++ b/lib/gitlab/error_tracking/processor/grpc_error_processor.rb
@@ -0,0 +1,71 @@
+# frozen_string_literal: true
+
+module Gitlab
+  module ErrorTracking
+    module Processor
+      class GrpcErrorProcessor < ::Raven::Processor
+        DEBUG_ERROR_STRING_REGEX = RE2('(.*) debug_error_string:(.*)')
+
+        def process(value)
+          return value unless grpc_exception?(value)
+
+          process_message(value)
+          process_exception_values(value)
+          process_custom_fingerprint(value)
+
+          value
+        end
+
+        def grpc_exception?(value)
+          value[:exception] && value[:message].start_with?('GRPC::')
+        end
+
+        def process_message(value)
+          message, debug_str = split_debug_error_string(value[:message])
+
+          return unless message
+
+          value[:message] = message
+          extra = value[:extra] || {}
+          extra[:grpc_debug_error_string] = debug_str if debug_str
+        end
+
+        def process_exception_values(value)
+          exceptions = value.dig(:exception, :values)
+
+          return unless exceptions.is_a?(Array)
+
+          exceptions.each do |entry|
+            message, _ = split_debug_error_string(entry[:value])
+            entry[:value] = message if message
+          end
+        end
+
+        def process_custom_fingerprint(value)
+          fingerprint = value[:fingerprint]
+
+          return value unless custom_grpc_fingerprint?(fingerprint)
+
+          message, _ = split_debug_error_string(fingerprint[1])
+          fingerprint[1] = message if message
+        end
+
+        private
+
+        def custom_grpc_fingerprint?(fingerprint)
+          fingerprint.is_a?(Array) && fingerprint.length == 2 && fingerprint[0].start_with?('GRPC::')
+        end
+
+        def split_debug_error_string(message)
+          return unless message
+
+          match = DEBUG_ERROR_STRING_REGEX.match(message)
+
+          return unless match
+
+          [match[1], match[2]]
+        end
+      end
+    end
+  end
+end
diff --git a/qa/qa/page/merge_request/show.rb b/qa/qa/page/merge_request/show.rb
index 906ad490bb181965ca6f5dab484392169cb30e56..4facd4a20778ed4d65d7f0fd5c59cd174cf3cdcd 100644
--- a/qa/qa/page/merge_request/show.rb
+++ b/qa/qa/page/merge_request/show.rb
@@ -131,7 +131,7 @@ module QA
 
         def add_comment_to_diff(text)
           wait_until(sleep_interval: 5) do
-            has_text?("No newline at end of file")
+            has_css?('a[data-linenumber="1"]')
           end
           all_elements(:new_diff_line, minimum: 1).first.hover
           click_element(:diff_comment)
diff --git a/spec/features/issuables/close_reopen_report_toggle_spec.rb b/spec/features/issuables/close_reopen_report_toggle_spec.rb
index f442b25f5934cac97729ed4ff58e35d4fcad6cbc..5ea89a7984fa6e820658a63b97430c37a0644928 100644
--- a/spec/features/issuables/close_reopen_report_toggle_spec.rb
+++ b/spec/features/issuables/close_reopen_report_toggle_spec.rb
@@ -3,6 +3,8 @@
 require 'spec_helper'
 
 RSpec.describe 'Issuables Close/Reopen/Report toggle' do
+  include IssuablesHelper
+
   let(:user) { create(:user) }
 
   shared_examples 'an issuable close/reopen/report toggle' do
@@ -27,19 +29,11 @@ RSpec.describe 'Issuables Close/Reopen/Report toggle' do
       expect(container).not_to have_selector('.reopen-item')
     end
 
-    it 'changes the button when an item is selected' do
-      button = container.find('.issuable-close-button')
-
-      container.find('.dropdown-toggle').click
-      container.find('.report-item').click
-
-      expect(container).not_to have_selector('.dropdown-menu')
-      expect(button).to have_content('Report abuse')
-
+    it 'links to Report Abuse' do
       container.find('.dropdown-toggle').click
-      container.find('.close-item').click
+      container.find('.report-abuse-link').click
 
-      expect(button).to have_content("Close #{human_model_name}")
+      expect(page).to have_content('Report abuse to admin')
     end
   end
 
diff --git a/spec/features/issues/gfm_autocomplete_spec.rb b/spec/features/issues/gfm_autocomplete_spec.rb
index 3757985f99c78555f9a29283c65f2fd41a82a96a..0165fba9acec95d384ea8eee29fe365112010f75 100644
--- a/spec/features/issues/gfm_autocomplete_spec.rb
+++ b/spec/features/issues/gfm_autocomplete_spec.rb
@@ -763,6 +763,29 @@ RSpec.describe 'GFM autocomplete', :js do
       end
     end
 
+    shared_examples 'autocomplete suggestions' do
+      it 'suggests objects correctly' do
+        page.within '.timeline-content-form' do
+          find('#note-body').native.send_keys(object.class.reference_prefix)
+        end
+
+        page.within '.tribute-container' do
+          expect(page).to have_content(object.title)
+
+          find('ul li').click
+        end
+
+        expect(find('.new-note #note-body').value).to include(expected_body)
+      end
+    end
+
+    context 'merge requests' do
+      let(:object) { create(:merge_request, source_project: project) }
+      let(:expected_body) { object.to_reference }
+
+      it_behaves_like 'autocomplete suggestions'
+    end
+
     context 'when other notes are destroyed' do
       let!(:discussion) { create(:discussion_note_on_issue, noteable: issue, project: issue.project) }
 
diff --git a/spec/lib/gitlab/error_tracking/processor/grpc_error_processor_spec.rb b/spec/lib/gitlab/error_tracking/processor/grpc_error_processor_spec.rb
new file mode 100644
index 0000000000000000000000000000000000000000..efa88d53f367e54f6abb982faf84d8e74a443d9f
--- /dev/null
+++ b/spec/lib/gitlab/error_tracking/processor/grpc_error_processor_spec.rb
@@ -0,0 +1,75 @@
+# frozen_string_literal: true
+
+require 'spec_helper'
+
+RSpec.describe Gitlab::ErrorTracking::Processor::GrpcErrorProcessor do
+  describe '#process' do
+    subject { described_class.new }
+
+    context 'when there is no GRPC exception' do
+      let(:data) { { fingerprint: ['ArgumentError', 'Missing arguments'] } }
+
+      it 'leaves data unchanged' do
+        expect(subject.process(data)).to eq(data)
+      end
+    end
+
+    context 'when there is a GPRC exception with a debug string' do
+      let(:data) do
+        {
+          exception: {
+            values: [
+              {
+                value: "GRPC::DeadlineExceeded: 4:DeadlineExceeded. debug_error_string:{\"hello\":1}"
+              }
+            ]
+          },
+          extra: {
+            caller: 'test'
+          },
+          message: "GRPC::DeadlineExceeded: 4:DeadlineExceeded. debug_error_string:{\"hello\":1}",
+          fingerprint: [
+            "GRPC::DeadlineExceeded",
+            "4:Deadline Exceeded. debug_error_string:{\"created\":\"@1598938192.005782000\",\"description\":\"Error received from peer unix:/home/git/gitalypraefect.socket\",\"file\":\"src/core/lib/surface/call.cc\",\"file_line\":1055,\"grpc_message\":\"Deadline Exceeded\",\"grpc_status\":4}"
+          ]
+        }
+      end
+
+      let(:expected) do
+        {
+          message: "GRPC::DeadlineExceeded: 4:DeadlineExceeded.",
+          fingerprint: [
+            "GRPC::DeadlineExceeded",
+            "4:Deadline Exceeded."
+          ],
+          exception: {
+            values: [
+              {
+                value: "GRPC::DeadlineExceeded: 4:DeadlineExceeded."
+              }
+            ]
+          },
+          extra: {
+            caller: 'test',
+            grpc_debug_error_string: "{\"hello\":1}"
+         }
+        }
+      end
+
+      it 'removes the debug error string and stores it as an extra field' do
+        expect(subject.process(data)).to eq(expected)
+      end
+
+      context 'with no custom fingerprint' do
+        before do
+          data.delete(:fingerprint)
+          expected.delete(:fingerprint)
+        end
+
+        it 'removes the debug error string and stores it as an extra field' do
+          expect(subject.process(data)).to eq(expected)
+        end
+      end
+    end
+  end
+end