Add latest changes from gitlab-org/gitlab@master

23 files changed, 198 insertions, 216 deletions

diff --git a/.gitlab/CODEOWNERS b/.gitlab/CODEOWNERS
index 823c6243548..5d6d218ef81 100644
--- a/.gitlab/CODEOWNERS
+++ b/.gitlab/CODEOWNERS
@@ -1177,6 +1177,7 @@ lib/gitlab/checks/**
 /ee/app/models/ee/personal_access_token.rb
 /ee/app/models/ee/project_authorization.rb
 /ee/app/models/scim_oauth_access_token.rb
+/ee/app/models/members/member_role.rb
 /ee/app/serializers/scim_oauth_access_token_entity.rb
 /ee/app/services/arkose/token_verification_service.rb
 /ee/app/services/ee/auth/
@@ -1209,6 +1210,7 @@ lib/gitlab/checks/**
 /ee/lib/gitlab/geo/oauth/
 /ee/lib/gitlab/kerberos/
 /ee/lib/omni_auth/
+/ee/spec/requests/custom_roles/
 /ee/lib/system_check/geo/authorized_keys_check.rb
 /ee/lib/system_check/geo/authorized_keys_flag_check.rb
 /lib/api/entities/impersonation_token.rb
diff --git a/.gitlab/ci/review.gitlab-ci.yml b/.gitlab/ci/review.gitlab-ci.yml
index 224312bd8ee..d4b199a9a81 100644
--- a/.gitlab/ci/review.gitlab-ci.yml
+++ b/.gitlab/ci/review.gitlab-ci.yml
@@ -75,6 +75,10 @@ start-review-app-pipeline:
   stage: review
   needs:
     - job: e2e-test-pipeline-generate
+    - job: rails-production-server-boot-puma-example
+      optional: true
+    - job: rails-production-server-boot-puma-cng
+      optional: true
     - job: build-assets-image
       artifacts: false
   # We do not want to have ALL global variables passed as trigger variables,
diff --git a/app/assets/javascripts/ci/runner/components/runner_platforms_radio_group.vue b/app/assets/javascripts/ci/runner/components/runner_platforms_radio_group.vue
index a49641194a7..a841f66b566 100644
--- a/app/assets/javascripts/ci/runner/components/runner_platforms_radio_group.vue
+++ b/app/assets/javascripts/ci/runner/components/runner_platforms_radio_group.vue
@@ -55,7 +55,7 @@ export default {
     <div class="gl-mt-3 gl-mb-6">
       <label>{{ s__('Runners|Operating systems') }}</label>
 
-      <div class="gl-display-flex gl-flex-wrap gl-gap-5">
+      <div class="gl-display-flex gl-flex-wrap gl-gap-3">
         <!-- eslint-disable @gitlab/vue-require-i18n-strings -->
         <runner-platforms-radio
           v-model="model"
@@ -76,7 +76,7 @@ export default {
     <div class="gl-mt-3 gl-mb-6">
       <label>{{ s__('Runners|Containers') }}</label>
 
-      <div class="gl-display-flex gl-flex-wrap gl-gap-5">
+      <div class="gl-display-flex gl-flex-wrap gl-gap-3">
         <!-- eslint-disable @gitlab/vue-require-i18n-strings -->
         <runner-platforms-radio :image="$options.DOCKER_LOGO_URL">
           <gl-link :href="$options.DOCKER_HELP_URL" target="_blank">
diff --git a/app/models/issue.rb b/app/models/issue.rb
index 41ccc15852d..58383a6a329 100644
--- a/app/models/issue.rb
+++ b/app/models/issue.rb
@@ -710,8 +710,8 @@ class Issue < ApplicationRecord
   end
 
   def expire_etag_cache
-    # TODO: Fix this for the case when issues is created at group level
-    # TODO: https://gitlab.com/gitlab-org/gitlab/-/work_items/395814
+    # We don't expire the cache for issues that don't have a project, since they are created at the group level
+    # and they are only displayed in the new work item view that uses GraphQL subscriptions for real-time updates
     return unless project
 
     key = Gitlab::Routing.url_helpers.realtime_changes_project_issue_path(project, self)
diff --git a/app/services/packages/npm/generate_metadata_service.rb b/app/services/packages/npm/generate_metadata_service.rb
index cae086d74c5..8eaac547f7e 100644
--- a/app/services/packages/npm/generate_metadata_service.rb
+++ b/app/services/packages/npm/generate_metadata_service.rb
@@ -41,17 +41,11 @@ module Packages
         package_versions = {}
 
         packages.each_batch do |relation|
-          batched_packages = if optimization_enabled?
-                               load_dependencies(relation)
-                               load_dependency_ids(relation)
-
-                               relation.preload_files
-                                       .preload_npm_metadatum
-                             else
-                               relation.including_dependency_links
-                                       .preload_files
-                                       .preload_npm_metadatum
-                             end
+          load_dependencies(relation)
+          load_dependency_ids(relation)
+
+          batched_packages = relation.preload_files
+                             .preload_npm_metadatum
 
           batched_packages.each do |package|
             package_file = package.installable_package_files.last
@@ -93,25 +87,18 @@ module Packages
       end
 
       def build_package_dependencies(package)
-        if optimization_enabled?
-          inverted_dependency_types = Packages::DependencyLink.dependency_types.invert.stringify_keys
-          dependency_ids[package.id].each_with_object(Hash.new { |h, key| h[key] = {} }) do |(type, ids), memo|
-            ids.each do |id|
-              memo[inverted_dependency_types[type]].merge!(dependencies[id])
-            end
+        dependency_ids[package.id].each_with_object(Hash.new { |h, key| h[key] = {} }) do |(type, ids), memo|
+          ids.each do |id|
+            memo[inverted_dependency_types[type]].merge!(dependencies[id])
           end
-        else
-          dependencies = Hash.new { |h, key| h[key] = {} }
-
-          package.dependency_links.each do |dependency_link|
-            dependency = dependency_link.dependency
-            dependencies[dependency_link.dependency_type][dependency.name] = dependency.version_pattern
-          end
-
-          dependencies
         end
       end
 
+      def inverted_dependency_types
+        Packages::DependencyLink.dependency_types.invert.stringify_keys
+      end
+      strong_memoize_attr :inverted_dependency_types
+
       def sorted_versions
         versions = packages.pluck_versions.compact
         VersionSorter.sort(versions)
@@ -151,11 +138,6 @@ module Packages
             end
           end
       end
-
-      def optimization_enabled?
-        Feature.enabled?(:npm_optimize_metadata_generation)
-      end
-      strong_memoize_attr :optimization_enabled?
     end
   end
 end
diff --git a/config/feature_flags/development/npm_optimize_metadata_generation.yml b/config/feature_flags/development/custom_roles_ui_saas.yml
index 173e48b51d1..26c85207357 100644
--- a/config/feature_flags/development/npm_optimize_metadata_generation.yml
+++ b/config/feature_flags/development/custom_roles_ui_saas.yml
@@ -1,8 +1,8 @@
 ---
-name: npm_optimize_metadata_generation
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/128514
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/416346
+name: custom_roles_ui_saas
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/130089
+rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/423077
 milestone: '16.4'
 type: development
-group: group::package registry
+group: group::authentication and authorization
 default_enabled: false
diff --git a/doc/architecture/blueprints/cells/index.md b/doc/architecture/blueprints/cells/index.md
index 4241bd562e5..bbf33d6bbd5 100644
--- a/doc/architecture/blueprints/cells/index.md
+++ b/doc/architecture/blueprints/cells/index.md
@@ -410,3 +410,4 @@ TBD
 - [Database group investigation](https://about.gitlab.com/handbook/engineering/development/enablement/data_stores/database/doc/root-namespace-sharding.html)
 - [Shopify Pods architecture](https://shopify.engineering/a-pods-architecture-to-allow-shopify-to-scale)
 - [Opstrace architecture](https://gitlab.com/gitlab-org/opstrace/opstrace/-/blob/main/docs/architecture/overview.md)
+- [Adding Diagrams to this blueprint](diagrams/index.md)
diff --git a/doc/ci/components/catalog.md b/doc/ci/components/catalog.md
index 12e795073b7..2194e72d56c 100644
--- a/doc/ci/components/catalog.md
+++ b/doc/ci/components/catalog.md
@@ -4,11 +4,11 @@ group: Pipeline Authoring
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# CI/CD Catalog **(PREMIUM ALL EXPERIMENT)**
+# CI/CD catalog **(PREMIUM ALL EXPERIMENT)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/407249) in GitLab 16.1.
 
-The CI/CD Catalog is a list of [components repositories](index.md#components-repository),
+The CI/CD catalog is a list of [components repositories](index.md#components-repository),
 each containing resources that you can add to your CI/CD pipelines.
 
 ## Mark a components repository as a catalog resource
diff --git a/doc/ci/components/index.md b/doc/ci/components/index.md
index 881cb931a0a..e73436522dc 100644
--- a/doc/ci/components/index.md
+++ b/doc/ci/components/index.md
@@ -4,7 +4,7 @@ group: Pipeline Authoring
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# CI/CD Components **(FREE ALL EXPERIMENT)**
+# CI/CD components **(FREE ALL EXPERIMENT)**
 
 > - Introduced as an [experimental feature](../../policy/experiment-beta-support.md) in GitLab 16.0, [with a flag](../../administration/feature_flags.md) named `ci_namespace_catalog_experimental`. Disabled by default.
 > - [Enabled on GitLab.com and self-managed](https://gitlab.com/groups/gitlab-org/-/epics/9897) in GitLab 16.2.
@@ -13,10 +13,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 This feature is an experimental feature and [an epic exists](https://gitlab.com/groups/gitlab-org/-/epics/9897)
 to track future work. Tell us about your use case by leaving comments in the epic.
 
-## Components Repository
+## Components repository
 
 A components repository is a GitLab project with a repository that hosts one or more pipeline components.
-A pipeline component is a reusable single pipeline configuration unit. You can use them to compose
+A pipeline component is a reusable single pipeline configuration unit. Use them to compose
 an entire pipeline configuration or a small part of a larger pipeline.
 
 A component can optionally take [input parameters](../yaml/inputs.md).
@@ -160,7 +160,7 @@ Nesting of components is not possible. For example:
 
 ## Release a component
 
-To create a release for a CI/CD component, you can use:
+To create a release for a CI/CD component, use either:
 
 - The [`release`](../yaml/index.md#release) keyword in a CI/CD pipeline. Like in the
   [component testing example](#test-the-component), you can set a component to automatically
@@ -186,19 +186,22 @@ include:
       stage: build
 ```
 
-The component is identified by a unique address in the form `<fully-qualified-doman-name>/<component-path>@<specific-version>`,
+The component is identified by a unique address in the form `<fully-qualified-domain-name>/<component-path>@<specific-version>`,
 where:
 
-- `<fully-qualified-doman-name>` matches the GitLab host.
+- `<fully-qualified-domain-name>` matches the GitLab host. You can only reference components
+  in the same GitLab instance as your project.
 - `<component-path>` is the component project's full path and directory where the
   component YAML file is located.
 - `<specific-version>` is the version of the component. In order of highest priority first,
   the version can be:
+  - A branch name, for example `main`.
   - A commit SHA, for example `e3262fdd0914fa823210cdb79a8c421e2cef79d8`.
-  - A tag, for example: `1.0`.
+  - A tag, for example: `1.0`. If a tag and branch exist with the same name, the tag
+    takes precedence over the branch. If a tag and commit SHA exist with the same name,
+    the commit SHA takes precedence over the tag.
   - `~latest`, which is a special version that always points to the most recent released tag.
-    Only available if the component has been [released](#release-a-component).
-  - A branch name, for example `main`.
+    Available only if the component has been [released](#release-a-component).
 
 For example, for a component repository located at `gitlab-org/dast` on `gitlab.com`,
 the path:
@@ -212,22 +215,15 @@ the path:
 - `gitlab.com/gitlab-org/dast/api-scan@main` targets a different file, the `template.yml`
   in the `/api-scan` directory in the component repository, for the `main` branch.
 
-**Additional details**:
-
-- You can only reference components in the same GitLab instance as your project.
-- If a tag and branch exist with the same name, the tag takes precedence over the branch.
-- If a tag is named the same as a commit SHA that exists, like `e3262fdd0914fa823210cdb79a8c421e2cef79d8`,
-  the commit SHA takes precedence over the tag.
-
 ## Best practices
 
 ### Avoid using global keywords
 
-You should try to avoid [global keywords](../yaml/index.md#global-keywords) in a component.
+Avoid using [global keywords](../yaml/index.md#global-keywords) in a component.
 Using these keywords in a component affects all jobs in a pipeline, including jobs
 directly defined in the main `.gitlab-ci.yml` or in other included components.
 
-As an alternative to global keywords, you should instead:
+As an alternative to global keywords, instead:
 
 - Add the configuration directly to each job, even if it creates some duplication
   in the component configuration.
@@ -280,7 +276,7 @@ Instead, you can:
 
 ### Replace hard-coded values with inputs
 
-You should avoid hard-coding values in a CI/CD components. Hard-coded values might force
+Avoid hard-coding values in CI/CD components. Hard-coded values might force
 component users to need to review the component's internal details and adapt their pipeline
 to work with the component.
 
@@ -324,13 +320,13 @@ For example:
 
 ### Replace custom CI/CD variables with inputs
 
-When using CI/CD variables in a component, you should evaluate if the `inputs` keyword
-should be used instead. Requiring a user to define custom variables to change a component's
-behavior should be avoided. You should try to use `inputs` for any component customization.
+When using CI/CD variables in a component, evaluate if the `inputs` keyword
+should be used instead. Avoid requiring a user to define custom variables to change a component's
+behavior. You should try to use `inputs` for any component customization.
 
-Inputs are explicitly defined in the component's specs and are better validated than variables.
+Inputs are explicitly defined in the component's specs, and are better validated than variables.
 For example, if a required input is not passed to the component, GitLab returns a pipeline error.
-By contrast, if a variable is not defined, it's value is empty and there is no error.
+By contrast, if a variable is not defined, its value is empty, and there is no error.
 
 For example, use `inputs` instead of variables to let users change a scanner's output format:
 
@@ -364,10 +360,10 @@ In other cases, CI/CD variables are still preferred, including:
 ### Use semantic versioning
 
 When tagging and releasing new versions of components, you should use [semantic versioning](https://semver.org).
-Semantic versioning is the standard for communicating that a change is a major, minor, patch
+Semantic versioning is the standard for communicating that a change is a major, minor, patch,
 or other kind of change.
 
-You should use at least the `major.minor` format, as this is widely understood, for example
+You should use at least the `major.minor` format, as this is widely understood. For example,
 `2.0` or `2.1`.
 
 Other examples of semantic versioning:
@@ -382,7 +378,7 @@ Other examples of semantic versioning:
 Testing CI/CD components as part of the development workflow is strongly recommended
 and helps ensure consistent behavior.
 
-You can test changes in a CI/CD pipeline (like any other project) by creating a `.gitlab-ci.yml`
+Test changes in a CI/CD pipeline (like any other project) by creating a `.gitlab-ci.yml`
 in the root directory.
 
 For example:
@@ -397,8 +393,8 @@ include:
 stages: [build, test, release]
 
 # Expect `component-job` is added.
-# This is an example of testing that the included component works as expected.
-# You can leverage GitLab API endpoints or 3rd party tools to inspect data generated by the component.
+# This example tests that the included component works as expected.
+# You can inspect data generated by the component, use GitLab API endpoints or third-party tools.
 ensure-job-added:
   stage: test
   image: badouralix/curl-jq
@@ -423,7 +419,7 @@ create-release:
     description: "Release $CI_COMMIT_TAG of components repository $CI_PROJECT_PATH"
 ```
 
-After committing and pushing changes, the pipeline tests the component then releases it if the test passes.
+After committing and pushing changes, the pipeline tests the component, then releases it if the test passes.
 
 ## Convert a CI/CD template to a component
 
@@ -434,6 +430,9 @@ can be converted to a CI/CD component:
    to be grouped with other components, or create and set up a new components repository.
 1. Create a YAML file in the components repository according to the expected [directory structure](index.md#directory-structure).
 1. Copy the content of the original template YAML file into the new component YAML file.
-1. Refactor the new component's configuration to follow the [best practices](index.md#best-practices) for components.
+1. Refactor the new component's configuration to:
+   - Follow the [best practices](index.md#best-practices) for components.
+   - Improve the configuration, for example by enabling [merge request pipelines](../pipelines/merge_request_pipelines.md)
+     or making it [more efficient](../pipelines/pipeline_efficiency.md).
 1. Leverage the `.gitlab-ci.yml` in the components repository to [test changes to the component](index.md#test-the-component).
 1. Tag and [release the component](index.md#release-a-component).
diff --git a/doc/development/ai_architecture.md b/doc/development/ai_architecture.md
index 005254db7ee..28483b943d1 100644
--- a/doc/development/ai_architecture.md
+++ b/doc/development/ai_architecture.md
@@ -27,6 +27,25 @@ There are two primary reasons for this: the best AI models are cloud-based as th
 
 The AI Gateway (formerly the [model gateway](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist)) is a standalone-service that will give access to AI features to all users of GitLab, no matter which instance they are using: self-managed, dedicated or GitLab.com. The SaaS-based AI abstraction layer will transition to connecting to this gateway, rather than accessing cloud-based providers directly.
 
+Calls to the AI-gateway from GitLab-rails can be made using the
+[Abstraction Layer](ai_features/index.md#abstraction-layer).
+By default, these actions are performed asynchronously via a Sidekiq
+job to prevent long-running requests in Puma. It should be used for
+non-latency sensitive actions due to the added latency by Sidekiq.
+
+At the time of writing, the Abstraction Layer still directly calls the AI providers. This will be
+changed [in the future](https://gitlab.com/gitlab-org/gitlab/-/issues/424614).
+
+When a certain action is latency sensitive, we can decide to call the
+AI-gateway directly. This avoids the latency added by Sidekiq.
+[We already do this for `code_suggestions`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/api/code_suggestions.rb)
+which get handled by API endpoints nested in
+`/api/v4/code_suggestions`. For any new endpoints added, we should
+nest them within the `/api/v4/ai_assisted` namespace. Doing this will
+automatically route the requests on GitLab.com to the `ai-assisted`
+fleet for GitLab.com, isolating the workload from the regular API and
+making it easier to scale if needed.
+
 ## Supported technologies
 
 As part of the AI working group, we have been investigating various technologies and vetting them. Below is a list of the tools which have been reviewed and already approved for use within the GitLab application.
diff --git a/doc/update/versions/gitlab_15_changes.md b/doc/update/versions/gitlab_15_changes.md
index a2e7b204a82..446c7588535 100644
--- a/doc/update/versions/gitlab_15_changes.md
+++ b/doc/update/versions/gitlab_15_changes.md
@@ -36,9 +36,27 @@ see [Packaged PostgreSQL deployed in an HA/Geo Cluster](https://docs.gitlab.com/
 ### Geo installations **(PREMIUM SELF)**
 
 - Some project imports do not initialize wiki repositories on project creation. See
-  [the details and workaround](#geo-wiki-repositories-not-initialized-on-project-creation).
+  [the details and workaround](gitlab_16_changes.md#wiki-repositories-not-initialized-on-project-creation).
 - `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13. See
-  [the details and workaround](#geo-pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
+  [the details and workaround](#pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
+
+#### `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13
+
+| Affected minor releases | Affected patch releases | Fixed in |
+|-------------------------|-------------------------|----------|
+| 15.2 - 15.10            | All                     | None     |
+| 15.11                   | 15.11.0 - 15.11.11      | 15.11.12 and later |
+
+A [bug](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7841) in the
+built-in `pg-upgrade` tool prevents upgrading the bundled PostgreSQL database
+to version 13. This leaves the secondary site in a broken state, and prevents
+upgrading the Geo installation to GitLab 16.x
+([PostgreSQL 12 support has removed in 16.0](../deprecations.md#postgresql-12-deprecated) and later
+releases). This occurs on secondary sites using the bundled PostgreSQL
+software, running both the secondary main Rails database and tracking database
+on the same node. There is a manual
+[workaround](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7841#workaround)
+if you can't upgrade to 15.11.12 and later.
 
 ## 15.11.x
 
@@ -114,7 +132,7 @@ see [Packaged PostgreSQL deployed in an HA/Geo Cluster](https://docs.gitlab.com/
 ### Geo installations **(PREMIUM SELF)**
 
 - `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13. See
-  [the details and workaround](#geo-pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
+  [the details and workaround](#pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
 
 ## 15.9.0
 
@@ -156,7 +174,7 @@ see [Packaged PostgreSQL deployed in an HA/Geo Cluster](https://docs.gitlab.com/
 ### Geo installations **(PREMIUM SELF)**
 
 - `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13. See
-  [the details and workaround](#geo-pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
+  [the details and workaround](#pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
 
 ## 15.8.2
 
@@ -184,7 +202,7 @@ see [Packaged PostgreSQL deployed in an HA/Geo Cluster](https://docs.gitlab.com/
 ### Geo installations **(PREMIUM SELF)**
 
 - `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13. See
-  [the details and workaround](#geo-pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
+  [the details and workaround](#pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
 - We discovered an issue where [replication and verification of projects and wikis was not keeping up](https://gitlab.com/gitlab-org/gitlab/-/issues/387980) on small number of Geo installations. Your installation may be affected if you see some projects and/or wikis persistently in the "Queued" state for verification. This can lead to data loss after a failover.
   - Affected versions: GitLab versions 15.6.x, 15.7.x, and 15.8.0 - 15.8.2.
   - Versions containing fix: GitLab 15.8.3 and later.
@@ -304,7 +322,7 @@ see [Packaged PostgreSQL deployed in an HA/Geo Cluster](https://docs.gitlab.com/
 ### Geo installations **(PREMIUM SELF)**
 
 - `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13. See
-  [the details and workaround](#geo-pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
+  [the details and workaround](#pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
 - [Container registry push events are rejected](https://gitlab.com/gitlab-org/gitlab/-/issues/386389) by the `/api/v4/container_registry_event/events` endpoint resulting in Geo secondary sites not being aware of updates to container registry images and subsequently not replicating the updates. Secondary sites may contain out of date container images after a failover as a consequence. This affects versions 15.6.0 - 15.6.6 and 15.7.0 - 15.7.2. If you're using Geo with container repositories, you are advised to upgrade to GitLab 15.6.7, 15.7.3, or 15.8.0 which contain a fix for this issue and avoid potential data loss after a failover.
 - We discovered an issue where [replication and verification of projects and wikis was not keeping up](https://gitlab.com/gitlab-org/gitlab/-/issues/387980) on small number of Geo installations. Your installation may be affected if you see some projects and/or wikis persistently in the "Queued" state for verification. This can lead to data loss after a failover.
   - Affected versions: GitLab versions 15.6.x, 15.7.x, and 15.8.0 - 15.8.2.
@@ -411,7 +429,7 @@ potentially cause downtime.
 ### Geo installations **(PREMIUM SELF)**
 
 - `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13. See
-  [the details and workaround](#geo-pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
+  [the details and workaround](#pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
 - [Container registry push events are rejected](https://gitlab.com/gitlab-org/gitlab/-/issues/386389) by the `/api/v4/container_registry_event/events` endpoint resulting in Geo secondary sites not being aware of updates to container registry images and subsequently not replicating the updates. Secondary sites may contain out of date container images after a failover as a consequence. This affects versions 15.6.0 - 15.6.6 and 15.7.0 - 15.7.2. If you're using Geo with container repositories, you are advised to upgrade to GitLab 15.6.7, 15.7.3, or 15.8.0 which contain a fix for this issue and avoid potential data loss after a failover.
 - We discovered an issue where [replication and verification of projects and wikis was not keeping up](https://gitlab.com/gitlab-org/gitlab/-/issues/387980) on small number of Geo installations. Your installation may be affected if you see some projects and/or wikis persistently in the "Queued" state for verification. This can lead to data loss after a failover.
   - Affected versions: GitLab versions 15.6.x, 15.7.x, and 15.8.0 - 15.8.2.
@@ -477,7 +495,7 @@ potentially cause downtime.
 ### Geo installations **(PREMIUM SELF)**
 
 - `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13. See
-  [the details and workaround](#geo-pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
+  [the details and workaround](#pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
 
 ## 15.4.6
 
@@ -549,7 +567,7 @@ potentially cause downtime.
 ### Geo installations **(PREMIUM SELF)**
 
 - `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13. See
-  [the details and workaround](#geo-pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
+  [the details and workaround](#pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
 
 ## 15.3.4
 
@@ -619,11 +637,45 @@ A [license caching issue](https://gitlab.com/gitlab-org/gitlab/-/issues/376706)
 ### Geo installations **(PREMIUM SELF)**
 
 - `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13. See
-  [the details and workaround](#geo-pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
+  [the details and workaround](#pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
 - LFS transfers can redirect to the primary from secondary site mid-session. See
-  [the details and workaround](#geo-lfs-transfers-redirect-to-primary-from-secondary-site-mid-session).
+  [the details and workaround](#lfs-transfers-redirect-to-primary-from-secondary-site-mid-session).
 - Incorrect object storage LFS files deletion on Geo secondary sites. See
-  [the details and workaround](#geo-incorrect-object-storage-lfs-file-deletion-on-secondary-sites).
+  [the details and workaround](#incorrect-object-storage-lfs-file-deletion-on-secondary-sites).
+
+#### LFS transfers redirect to primary from secondary site mid-session
+
+| Affected minor releases | Affected patch releases | Fixed in |
+|-------------------------|-------------------------|----------|
+| 15.1                    | All                     | None     |
+| 15.2                    | All                     | None     |
+| 15.3                    | 15.3.0 - 15.3.2         | 15.3.3 and later |
+
+LFS transfers can [redirect to the primary from secondary site mid-session](https://gitlab.com/gitlab-org/gitlab/-/issues/371571) causing failed pull and clone requests in GitLab 15.1.0 to 15.3.2 when [Geo proxying](../../administration/geo/secondary_proxy/index.md) is enabled. Geo proxying is enabled by default in GitLab 15.1 and later.
+
+This issue is resolved in GitLab 15.3.3, so customers with the following configuration should upgrade to 15.3.3 or later:
+
+- LFS is enabled.
+- LFS objects are being replicated across Geo sites.
+- Repositories are being pulled by using a Geo secondary site.
+
+#### Incorrect object storage LFS file deletion on secondary sites
+
+| Affected minor releases | Affected patch releases | Fixed in |
+|-------------------------|-------------------------|----------|
+| 15.0                    | All                     | None     |
+| 15.1                    | All                     | None     |
+| 15.2                    | All                     | None     |
+| 15.3                    | 15.3.0 - 15.3.2         | 15.3.3 and later |
+
+[Incorrect deletion of object storage files on Geo secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/371397)
+can occur in GitLab 15.0.0 to 15.3.2 in the following situations:
+
+- GitLab-managed object storage replication is disabled, and LFS objects are created while importing a project with object storage enabled.
+- GitLab-managed replication to sync object storage is enabled and subsequently disabled.
+
+This issue is resolved in 15.3.3. Customers who have both LFS enabled and LFS objects being replicated across Geo sites
+should upgrade directly to 15.3.3 to reduce the risk of data loss on secondary sites.
 
 ## 15.2.5
 
@@ -657,11 +709,11 @@ A [license caching issue](https://gitlab.com/gitlab-org/gitlab/-/issues/376706)
 ### Geo installations **(PREMIUM SELF)**
 
 - `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13. See
-  [the details and workaround](#geo-pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
+  [the details and workaround](#pg_upgrade-fails-to-upgrade-the-bundled-postregsql-database-to-version-13).
 - LFS transfers can redirect to the primary from secondary site mid-session. See
-  [the details and workaround](#geo-lfs-transfers-redirect-to-primary-from-secondary-site-mid-session).
+  [the details and workaround](#lfs-transfers-redirect-to-primary-from-secondary-site-mid-session).
 - Incorrect object storage LFS files deletion on Geo secondary sites. See
-  [the details and workaround](#geo-incorrect-object-storage-lfs-file-deletion-on-secondary-sites).
+  [the details and workaround](#incorrect-object-storage-lfs-file-deletion-on-secondary-sites).
 
 ## 15.1.0
 
@@ -697,9 +749,9 @@ A [license caching issue](https://gitlab.com/gitlab-org/gitlab/-/issues/376706)
 
 - [Geo proxying](../../administration/geo/secondary_proxy/index.md) was [enabled by default for different URLs](https://gitlab.com/gitlab-org/gitlab/-/issues/346112) in 15.1. This may be a breaking change. If needed, you may [disable Geo proxying](../../administration/geo/secondary_proxy/index.md#disable-geo-proxying). If you are using SAML with different URLs, you must modify your SAML configuration and your Identity Provider configuration. For more information, see the [Geo with Single Sign-On (SSO) documentation](../../administration/geo/replication/single_sign_on.md).
 - LFS transfers can redirect to the primary from secondary site mid-session. See
-  [the details and workaround](#geo-lfs-transfers-redirect-to-primary-from-secondary-site-mid-session).
+  [the details and workaround](#lfs-transfers-redirect-to-primary-from-secondary-site-mid-session).
 - Incorrect object storage LFS files deletion on Geo secondary sites. See
-  [the details and workaround](#geo-incorrect-object-storage-lfs-file-deletion-on-secondary-sites).
+  [the details and workaround](#incorrect-object-storage-lfs-file-deletion-on-secondary-sites).
 
 ## 15.0.0
 
@@ -863,78 +915,4 @@ A [license caching issue](https://gitlab.com/gitlab-org/gitlab/-/issues/376706)
 ### Geo installations **(PREMIUM SELF)**
 
 - Incorrect object storage LFS files deletion on Geo secondary sites. See
-  [the details and workaround](#geo-incorrect-object-storage-lfs-file-deletion-on-secondary-sites).
-
-## Issues affecting multiple versions
-
-The following issues affect more than one version. Refer to the tables
-to find which version you should upgrade to.
-
-### Geo: LFS transfers redirect to primary from secondary site mid-session
-
-| Affected minor releases | Affected patch releases | Fixed in |
-| ------ | ------ | ------ |
-| 15.1   | All    | None   |
-| 15.2   | All    | None   |
-| 15.3   | 15.3.0 - 15.3.2   | 15.3.3 and later       |
-
-LFS transfers can [redirect to the primary from secondary site mid-session](https://gitlab.com/gitlab-org/gitlab/-/issues/371571) causing failed pull and clone requests in GitLab 15.1.0 to 15.3.2 when [Geo proxying](../../administration/geo/secondary_proxy/index.md) is enabled. Geo proxying is enabled by default in GitLab 15.1 and later.
-
-This issue is resolved in GitLab 15.3.3, so customers with the following configuration should upgrade to 15.3.3 or later:
-
-- LFS is enabled.
-- LFS objects are being replicated across Geo sites.
-- Repositories are being pulled by using a Geo secondary site.
-
-### Geo: Incorrect object storage LFS file deletion on secondary sites
-
-| Affected minor releases | Affected patch releases | Fixed in |
-| ------ | ------ | ------ |
-| 15.0   | All    | None   |
-| 15.1   | All    | None   |
-| 15.2   | All    | None   |
-| 15.3   | 15.3.0 - 15.3.2   | 15.3.3 and later       |
-
-[Incorrect deletion of object storage files on Geo secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/371397)
-can occur in GitLab 15.0.0 to 15.3.2 in the following situations:
-
-- GitLab-managed object storage replication is disabled, and LFS objects are created while importing a project with object storage enabled.
-- GitLab-managed replication to sync object storage is enabled and subsequently disabled.
-
-This issue is resolved in 15.3.3. Customers who have both LFS enabled and LFS objects being replicated across Geo sites
-should upgrade directly to 15.3.3 to reduce the risk of data loss on secondary sites.
-
-### Geo: Wiki repositories not initialized on project creation
-
-| Affected minor releases | Affected patch releases | Fixed in |
-| ------- | ------ | ------ |
-| 15.11   | All    | None   |
-| 16.0    | All    | None   |
-| 16.1    | 16.1.0 - 16.1.2    | 16.1.3 and later   |
-
-Some project imports do not initialize wiki repositories on project creation.
-Since the migration of project wikis to SSF,
-[missing wiki repositories are being incorrectly flagged as failing verification](https://gitlab.com/gitlab-org/gitlab/-/issues/409704).
-This is not a result of an actual replication/verification failure but an
-invalid internal state for these missing repositories inside Geo and results in
-errors in the logs and the verification progress reporting a failed state for
-these wiki repositories. If you have not imported projects you are not impacted
-by this issue.
-
-### Geo: `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13
-
-| Affected minor releases | Affected patch releases | Fixed in |
-| ------- | ------ | ------ |
-| 15.2 - 15.10    | All    | None   |
-| 15.11    | 15.11.0 - 15.11.11    | 15.11.12 and later   |
-
-A [bug](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7841) in the
-built-in `pg-upgrade` tool prevents upgrading the bundled PostgreSQL database
-to version 13. This leaves the secondary site in a broken state, and prevents
-upgrading the Geo installation to GitLab 16.x
-([PostgreSQL 12 support has removed in 16.0](../deprecations.md#postgresql-12-deprecated) and later
-releases). This occurs on secondary sites using the bundled PostgreSQL
-software, running both the secondary main Rails database and tracking database
-on the same node. There is a manual
-[workaround](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7841#workaround)
-if you can't upgrade to 15.11.12 and later.
+  [the details and workaround](#incorrect-object-storage-lfs-file-deletion-on-secondary-sites).
diff --git a/doc/update/versions/gitlab_16_changes.md b/doc/update/versions/gitlab_16_changes.md
index 1ce58c3f358..353f72ff07a 100644
--- a/doc/update/versions/gitlab_16_changes.md
+++ b/doc/update/versions/gitlab_16_changes.md
@@ -197,13 +197,8 @@ Specific information applies to installations using Geo:
 
 Specific information applies to installations using Geo:
 
-- Some project imports do not initialize wiki repositories on project creation. Because of the migration of project wikis to
-  SSF, [missing wiki repositories are being incorrectly flagged as failing verification](https://gitlab.com/gitlab-org/gitlab/-/issues/409704).
-  This issue is not a result of an actual replication/verification failure but an invalid internal state for these missing
-  repositories inside Geo and results in errors in the logs and the verification progress reporting a failed state for
-  these wiki repositories. If you have not imported projects you are not impacted by this issue.
-  - Impacted versions: GitLab versions 15.11.x, 16.0.x, and 16.1.0 - 16.1.2.
-  - Versions containing fix: GitLab 16.1.3 and later.
+- Some project imports do not initialize wiki repositories on project creation. See
+  [the details and workaround](#wiki-repositories-not-initialized-on-project-creation).
 - Because of the migration of project designs to SSF, [missing design repositories are being incorrectly flagged as failing verification](https://gitlab.com/gitlab-org/gitlab/-/issues/414279).
   This issue is not a result of an actual replication/verification failure but an invalid internal state for these missing
   repositories inside Geo and results in errors in the logs and the verification progress reporting a failed state for
@@ -217,6 +212,23 @@ Specific information applies to installations using Geo:
     Affected artifacts are automatically resynced upon upgrade to 16.1.5, 16.2.5, 16.3.1, 16.4.0, or later.
     You can [manually resync affected job artifacts](https://gitlab.com/gitlab-org/gitlab/-/issues/419742#to-fix-data) if needed.
 
+#### Wiki repositories not initialized on project creation
+
+| Affected minor releases | Affected patch releases | Fixed in |
+|-------------------------|-------------------------|----------|
+| 15.11                   | All                     | None     |
+| 16.0                    | All                     | None     |
+| 16.1                    | 16.1.0 - 16.1.2         | 16.1.3 and later |
+
+Some project imports do not initialize wiki repositories on project creation.
+Since the migration of project wikis to SSF,
+[missing wiki repositories are being incorrectly flagged as failing verification](https://gitlab.com/gitlab-org/gitlab/-/issues/409704).
+This is not a result of an actual replication/verification failure but an
+invalid internal state for these missing repositories inside Geo and results in
+errors in the logs and the verification progress reporting a failed state for
+these wiki repositories. If you have not imported projects you are not impacted
+by this issue.
+
 ## 16.0.0
 
 - Sidekiq crashes if there are non-ASCII characters in the `/etc/gitlab/gitlab.rb` file. You can fix this
@@ -259,14 +271,8 @@ Specific information applies to Linux package installations:
 
 Specific information applies to installations using Geo:
 
-- Some project imports do not initialize wiki repositories on project creation. Because of the migration of project wikis to
-  SSF, [missing wiki repositories are being incorrectly flagged as failing verification](https://gitlab.com/gitlab-org/gitlab/-/issues/409704).
-  This issue is not a result of an actual replication/verification failure but an invalid internal state for these missing
-  repositories inside Geo and results in errors in the logs and the verification progress reporting a failed state for
-  these wiki repositories. If you have not imported projects you are not impacted by this issue.
-
-  - Impacted versions: GitLab versions 15.11.x, 16.0.x, and 16.1.0 - 16.1.2.
-  - Versions containing fix: GitLab 16.1.3 and later.
+- Some project imports do not initialize wiki repositories on project creation. See
+  [the details and workaround](#wiki-repositories-not-initialized-on-project-creation).
 
 ### Gitaly configuration structure change
 
diff --git a/doc/user/permissions.md b/doc/user/permissions.md
index 246537216b7..d7510f26e9a 100644
--- a/doc/user/permissions.md
+++ b/doc/user/permissions.md
@@ -528,7 +528,7 @@ Prerequisite:
 1. Select the **Permissions** for the new custom role.
 1. Select **Create new role**.
 
-#### GitLab.com
+#### Self Managed GitLab Instances
 
 Prerequisite:
 
diff --git a/lib/gitlab/import_export/json/ndjson_writer.rb b/lib/gitlab/import_export/json/ndjson_writer.rb
index e303ac6eefa..60ae163cad5 100644
--- a/lib/gitlab/import_export/json/ndjson_writer.rb
+++ b/lib/gitlab/import_export/json/ndjson_writer.rb
@@ -44,12 +44,11 @@ module Gitlab
 
         def with_file(*path)
           file_path = File.join(@dir_path, *path)
-          raise ArgumentError, "The #{file_path} already exist" if File.exist?(file_path)
 
           # ensure that path is created
           mkdir_p(File.dirname(file_path))
 
-          File.open(file_path, "wb") do |file|
+          File.open(file_path, "ab+") do |file|
             yield(file)
           end
         end
diff --git a/lib/gitlab/import_export/json/streaming_serializer.rb b/lib/gitlab/import_export/json/streaming_serializer.rb
index 2c64ca53f76..b0951f24628 100644
--- a/lib/gitlab/import_export/json/streaming_serializer.rb
+++ b/lib/gitlab/import_export/json/streaming_serializer.rb
@@ -75,10 +75,12 @@ module Gitlab
         def serialize_many_relations(key, records, options)
           log_relation_export(key, records.size)
 
-          enumerator = Enumerator.new do |items|
-            key_preloads = preloads&.dig(key)
+          key_preloads = preloads&.dig(key)
+
+          batch(records, key) do |batch|
+            next if batch.empty?
 
-            batch(records, key) do |batch|
+            batch_enumerator = Enumerator.new do |items|
               batch = batch.preload(key_preloads) if key_preloads
 
               batch.each do |record|
@@ -91,9 +93,11 @@ module Gitlab
                 after_read_callback(record)
               end
             end
-          end
 
-          json_writer.write_relation_array(@exportable_path, key, enumerator)
+            json_writer.write_relation_array(@exportable_path, key, batch_enumerator)
+
+            Gitlab::SafeRequestStore.clear!
+          end
         end
 
         def exportable_json_record(record, options, key)
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index 12af1d4121b..7501db76a24 100644
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@@ -1959,7 +1959,7 @@ msgstr ""
 msgid "AI|Explain the code from %{filePath} in human understandable language presented in Markdown format. In the response add neither original code snippet nor any title. `%{text}`. If it is not programming code, say `The selected text is not code. I am afraid this feature is for explaining code only. Would you like to ask a different question about the selected text?` and wait for another question."
 msgstr ""
 
-msgid "AI|Explain your rating (optional)"
+msgid "AI|Explain your rating to help us improve! (optional)"
 msgstr ""
 
 msgid "AI|Features that use third-party AI services require transmission of data, including personal data."
@@ -29023,9 +29023,6 @@ msgstr ""
 msgid "MemberRole|maximum number of Member Roles are already in use by the group hierarchy. Please delete an existing Member Role."
 msgstr ""
 
-msgid "MemberRole|minimal base access level must be %{min_access_level}."
-msgstr ""
-
 msgid "MemberRole|must be top-level namespace"
 msgstr ""
 
diff --git a/spec/features/invites_spec.rb b/spec/features/invites_spec.rb
index c29da757c3a..a56df7bdecc 100644
--- a/spec/features/invites_spec.rb
+++ b/spec/features/invites_spec.rb
@@ -224,8 +224,7 @@ RSpec.describe 'Group or Project invitations', :aggregate_failures, feature_cate
         end
 
         context 'when the user signs up for an account with the invitation email address' do
-          it 'redirects to the most recent membership activity page with all invitations automatically accepted',
-            quarantine: 'https://gitlab.com/gitlab-org/gitlab/-/issues/417092' do
+          it 'redirects to the most recent membership activity page with all invitations automatically accepted' do
             fill_in_sign_up_form(new_user)
             fill_in_welcome_form
 
diff --git a/spec/features/projects/import_export/export_file_spec.rb b/spec/features/projects/import_export/export_file_spec.rb
index ad2fccc14bf..bda45da0fa5 100644
--- a/spec/features/projects/import_export/export_file_spec.rb
+++ b/spec/features/projects/import_export/export_file_spec.rb
@@ -38,6 +38,10 @@ RSpec.describe 'Import/Export - project export integration test', :js, feature_c
   context 'admin user' do
     before do
       sign_in(user)
+
+      # Now that we export project in batches we produce more queries than before
+      # needing to increase the default threshold
+      allow(Gitlab::QueryLimiting::Transaction).to receive(:threshold).and_return(200)
     end
 
     it 'exports a project successfully', :sidekiq_inline do
diff --git a/spec/lib/gitlab/import_export/json/ndjson_writer_spec.rb b/spec/lib/gitlab/import_export/json/ndjson_writer_spec.rb
index 452d63d548e..486d179ae05 100644
--- a/spec/lib/gitlab/import_export/json/ndjson_writer_spec.rb
+++ b/spec/lib/gitlab/import_export/json/ndjson_writer_spec.rb
@@ -2,7 +2,7 @@
 
 require "spec_helper"
 
-RSpec.describe Gitlab::ImportExport::Json::NdjsonWriter do
+RSpec.describe Gitlab::ImportExport::Json::NdjsonWriter, feature_category: :importers do
   include ImportExport::CommonUtil
 
   let(:path) { "#{Dir.tmpdir}/ndjson_writer_spec/tree" }
@@ -35,13 +35,18 @@ RSpec.describe Gitlab::ImportExport::Json::NdjsonWriter do
     end
 
     context "when single relation is already serialized" do
-      it "raise exception" do
+      it "appends to the existing file" do
         values = [{ "key" => "value_1", "key_1" => "value_1" }, { "key" => "value_2", "key_1" => "value_2" }]
         relation = "relation"
         file_path = File.join(path, exportable_path, "#{relation}.ndjson")
         subject.write_relation(exportable_path, relation, values[0])
 
-        expect { subject.write_relation(exportable_path, relation, values[1]) }.to raise_exception("The #{file_path} already exist")
+        expect { subject.write_relation(exportable_path, relation, values[1]) }.not_to raise_exception
+
+        file_data = File.read(file_path)
+
+        expect(file_data).to include(values[0].to_json)
+        expect(file_data).to include(values[1].to_json)
       end
     end
   end
diff --git a/spec/lib/gitlab/import_export/json/streaming_serializer_spec.rb b/spec/lib/gitlab/import_export/json/streaming_serializer_spec.rb
index f4c9189030b..e5058e029c8 100644
--- a/spec/lib/gitlab/import_export/json/streaming_serializer_spec.rb
+++ b/spec/lib/gitlab/import_export/json/streaming_serializer_spec.rb
@@ -70,8 +70,9 @@ RSpec.describe Gitlab::ImportExport::Json::StreamingSerializer, feature_category
         create_list(:issue, 3, :with_desc_relative_position, project: exportable ) # ascending ids, descending position
       end
 
-      it 'calls json_writer.write_relation_array with proper params' do
+      it 'calls json_writer.write_relation_array with proper params and clears SafeRequestStore' do
         expect(json_writer).to receive(:write_relation_array).with(exportable_path, :issues, array_including(issue.to_json))
+        expect(Gitlab::SafeRequestStore).to receive(:clear!)
 
         subject.execute
       end
diff --git a/spec/lib/gitlab/import_export/project/export_task_spec.rb b/spec/lib/gitlab/import_export/project/export_task_spec.rb
index 95971d08175..0837874526a 100644
--- a/spec/lib/gitlab/import_export/project/export_task_spec.rb
+++ b/spec/lib/gitlab/import_export/project/export_task_spec.rb
@@ -2,7 +2,7 @@
 
 require 'rake_helper'
 
-RSpec.describe Gitlab::ImportExport::Project::ExportTask, :silence_stdout do
+RSpec.describe Gitlab::ImportExport::Project::ExportTask, :silence_stdout, feature_category: :importers do
   let_it_be(:username) { 'root' }
   let(:namespace_path) { username }
   let_it_be(:user) { create(:user, username: username) }
diff --git a/spec/services/packages/npm/generate_metadata_service_spec.rb b/spec/services/packages/npm/generate_metadata_service_spec.rb
index c96a865786a..d8e794405e6 100644
--- a/spec/services/packages/npm/generate_metadata_service_spec.rb
+++ b/spec/services/packages/npm/generate_metadata_service_spec.rb
@@ -80,19 +80,6 @@ RSpec.describe ::Packages::Npm::GenerateMetadataService, feature_category: :pack
 
             subject
           end
-
-          context 'when npm_optimize_metadata_generation disabled' do
-            before do
-              stub_feature_flags(npm_optimize_metadata_generation: false)
-            end
-
-            it 'does not load grouped dependency links', :aggregate_failures do
-              expect(::Packages::DependencyLink).not_to receive(:dependency_ids_grouped_by_type)
-              expect(::Packages::Package).to receive(:including_dependency_links).and_call_original
-
-              subject
-            end
-          end
         end
       end
 
diff --git a/spec/support/finder_collection_allowlist.yml b/spec/support/finder_collection_allowlist.yml
index e7dd9cea922..860045c6ce6 100644
--- a/spec/support/finder_collection_allowlist.yml
+++ b/spec/support/finder_collection_allowlist.yml
@@ -62,11 +62,6 @@
 - Security::PipelineVulnerabilitiesFinder
 - Security::ScanExecutionPoliciesFinder
 - Security::ScanResultPoliciesFinder
-- Security::TrainingProviders::BaseUrlFinder
-- Security::TrainingUrlsFinder
-- Security::TrainingProviders::KontraUrlFinder
-- Security::TrainingProviders::SecureCodeWarriorUrlFinder
-- Security::TrainingProviders::SecureFlagUrlFinder
 - SentryIssueFinder
 - ServerlessDomainFinder
 - TagsFinder