Remove stong_memoization for cloud connector services
What does this MR do and why?
In https://gitlab.com/gitlab-org/gitlab/-/issues/476506 and while testing the cut_off date for the new AI enterprise features we noticed that when the CC configuration on CDot changes, some PUMA workers still have some stale data. See: #477177 (comment 2037993130) while testing
noticed the troubleshoot(root cause analysis) button appearing and dis-appearing on refresh on a SM instance yesterday.
This is because we are using a strong_memoization for CloudConnector::AvailableServices.available_services. This works well for Gitlab.com as the available services don't change because we don't synchronize available services with CustomersDot.
This is not the case for self-managed instances.
Although we do clear memoization when Access data is changed, this actually doesn't clear memorization for other Puma workers and caused this bug.
This MR removes stong_memoization from the following methods:
CloudConnector::AvailableServices.available_servicesCloudConnector::AvailableServices.access_data_readerCloudConnector::BaseAvailableServiceData.new.add_on_purchases(namespace = nil)
The strong_memoization was added in ee/lib/cloud_connector/self_signed/access_data_reader.rb as the Gitlab.com and instances who are self-hosting ai gateway are not syncing data with the CDOT. They use access_data.yml and to change that, they need to redeploy, which would restart the Puma workers and clear memorization on its own.
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
| Before | After |
|---|---|
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
Related to #17 (closed)