Fix flaky restrict_gitlab_schema_spec.rb
What does this MR do and why?
This backports !132694 (merged) to 16-3-stable-ee
.
This test was failing because Feature.enabled?(:redis_hll_tracking)
was called in the migration and expecting the feature_names
database
table to be accessed. However, it wasn't accessed for two reasons:
-
In tests we stub out feature flag access and use an in-memory cache. However, even though the test had
stub_feature_flags: false
set in the metadata, a staleFeature
was still memoized and had to be cleared out. More specifically, https://gitlab.com/gitlab-org/gitlab/-/blob/73607c34155759294e3aae4c94213d2a4c0bcefe/spec/spec_helper.rb#L253-254 callsstub_all_feature_flags
andstub_feature_flags(main_branch_over_master: false)
immediately before the test. As a result, there was a staleFlipper
instance at startup.unstub_all_feature_flags
won't work properly until it's cleared out. -
With the feature flag stubs disabled, this enabled the Redis cache for feature flags. We need to clear this out between tests to ensure the database is hit.
Relates to #416143 (closed)
How to set up and validate locally
Locally this test failed for me regularly via:
bundle exec rspec "./spec/lib/gitlab/database/migration_helpers/restrict_gitlab_schema_spec.rb[1:2:17:1:3:1]"
bundle exec rspec "./spec/lib/gitlab/database/migration_helpers/restrict_gitlab_schema_spec.rb
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Describe in detail what merge request is being backported and why
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch. -
The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes). -
This MR has a severity label assigned (if applicable). -
This MR has been approved by a maintainer (only one approval is required). -
Ensure the e2e:package-and-test-ee
job has either succeeded or been approved by a Software Engineer in Test.
Note to the merge request author and maintainer
If you have questions about the patch release process, please:
- Refer to the patch release runbook for engineers and maintainers for guidance.
- Ask questions on the
#releases
Slack channel (internal only).