Fix order-dependent ActionCable spec failure

What does this MR do and why?

If another spec uses ActionCable before the ActionCable initializer spec runs, then the current PubSub Redis connection will already be configured with a memoized identifier. The spec attempts to test a Redis configuration with a nil identifier to support GCP Memorystore, but for that to work we need to reset the Redis connection and cause the new config to be used.

This commit fixes the order-dependent test by clearing out the ActionCable server status before and after the test via ActionCable.server.restart.

Closes #418937 (closed)

How to set up and validate locally

Run:

bundle exec rspec spec/graphql/resolvers/users/participants_resolver_spec.rb spec/initializers/action_cable_subscription_adapter_identifier_spec.rb

On master, this fails with something like:

Failures:

  1) ActionCableSubscriptionAdapterIdentifier override #identifier when id key is nil on cable.yml does not override server config id with action cable pid
     Failure/Error: expect(sub.connection[:id]).to eq('unix:///home/localuser/redis/redis.socket/0')

       expected: "unix:///home/localuser/redis/redis.socket/0"
            got: "ActionCable-PID-54546"

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.

assigned to @stanhu

marked the checklist item I have evaluated the MR acceptance checklist for this MR. as completed

changed milestone to %16.3

added flaky-teststate leak maintenancepipelines typemaintenance labels

requested review from @engwan

changed the description

mentioned in issue #418937 (closed)

added backend label

Reviewer roulette

Changes that require review have been detected!

Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:

Category	Reviewer	Maintainer
backend	Siddharth Dungarwal (@sdungarwal) (UTC+5.5, 12.5 hours ahead of @stanhu)	Max Woolf (@mwoolf) (UTC+1, 8 hours ahead of @stanhu)

To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.

To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.

Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.

If needed, you can retry the danger-review job that generated this comment.

Generated by Danger

approved this merge request

@engwan, thanks for approving this merge request.

This is the first time the merge request is approved. To ensure full test coverage, a new pipeline will be started shortly.

For more info, please refer to the following links:

• rspec predictive jobs
• jest predictive jobs
• merging a merge request.

added pipeline:mr-approved label

Thanks for fixing this

enabled an automatic merge when the pipeline for ff8761c9 succeeds

merged

mentioned in commit 5e11252f

added workflowstaging-canary label

added workflowcanary label and removed workflowstaging-canary label

added workflowstaging label and removed workflowcanary label