<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary Local smoke tests are failing but passing in the CI pipeline so we commented out the failing tests in this [MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/185176). Here we want to update the tests in order to restore the test coverage. Investigation context thread: https://gitlab.slack.com/archives/C03KE0L9NC9/p1742328309075359 <!-- Summarize the bug encountered concisely. --> ### Steps to reproduce 1. Check out https://gitlab.com/gitlab-org/gitlab/-/tree/caw-ws-debugging-flaky-tests?ref_type=heads 2. Run `ENABLE_SPRING=1 bin/rspec -r spec_helper --format documentation --seed 22705 ee/spec/features/remote_development/debugging_flaky_tests_2_spec.rb` or run `SKIP_RUBOCOP=1 SKIP_FP=1 SKIP_FAST=1 SKIP_JEST=1 SKIP_NON_FAST=1 scripts/remote_development/run-smoke-test-suite.sh` <!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. --> ### What is the current *bug* behavior? It seems to be some interaction between specs when they are run as part of the same suite. Both `ee/spec/features/groups/settings/remote_development/workspaces_spec.rb` and `ee/spec/features/remote_development/workspaces_spec.rb` will fail, but only if they are run AFTER `ee/spec/features/remote_development/workspaces_dropdown_group_spec.rb` as part of the same suite. None of the Capybara failure screenshots or HTML captures seem to make sense - the elements look like they are there, but Capybara times out looking for them. ### What is the expected *correct* behavior? <!-- Describe what you should see instead. --> ### Relevant logs and/or screenshots <!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise. --> ### Output of checks <!-- If you are reporting a bug on GitLab.com, uncomment below --> <!-- This bug happens on GitLab.com --> <!-- and uncomment below if you have /label privileges --> <!-- /label ~"reproduced on GitLab.com" --> <!-- or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not --> #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->