Having lesser number of characters in the environments search string operation affects performance of the database for larger projects and this was discussed in the earlier feature implementation MR.
Creating this issue to follow up the fix for it, as limiting it to 3 or more characters in finder will be a breaking change on the public api.
I implemented the limit, but did so on the controller level(see the last commit).
I did it on the controller level because:
the problem with these count(*) is very specific to this controller
I'm afraid of breaking things if we change the API. I think it would require longer validation period for the feature flag including at least 1 release to validate it on self-managed.
It feels like a breaking change, so ideally I would do in on the major release.
Implementation Proposal
Have a FF scoped by project
When the FF is set, allow search operation only for term of length >= 3 characters. For less then 3 characters, the validation and status code returned can follow the same one that is used for limiting note/comment body in GitLab.
The FF will be enabled on gitlab.com following a gradual percentage based rollout monitoring errors.
For On-Premise since it can be a breaking change on the api , default enable of FF should be done in %16.0. After completion of step 3, create a follow up issue for default enabling FF in 16.0 and close the current issue.
Thanks @vshushlin@shinya.maeda I am also inclined to address this as the finder will still be used by public api (unless we introduce result limits for the API but that again will a breaking change as well) and also by other search feature enhancements like #382375
A “breaking change” is any change that requires users to make a corresponding change to their code, settings, or workflow. “Users” might be humans, API clients, or even code classes that “use” another class
A breaking change can be considered major if it affects many users, or represents a significant change in behavior.
I understand this may be a sensitive change because it could affect some workflows for self-managed but given the above description, I'm not convinced this could be a breaking change, particularly because no argument will be removed and the request will continue to work. This is a long-hanging fruit that could improve the performance of the Environments page and reduce the load into our database servers, it could be beneficial to implement this in the upcoming releases rather than waiting until 16.0
@cbalane Coming from !102227 (comment 1171742146) and looking at the data in #382532 (comment 1172563953), I think we can address this issue with a feature flag (scoped by project) that we can enable on gitlab.com in next milestone and if we are concerned about it being a breaking change on self managed the flag can be default enabled in %16.0 .
As a tradeoff we will have the FF in code till 16.0 but this is the possible iterative solution that I could think for now.
This issue describes a problem to solve, and it's confirmed.
This issue describes a proposal that outlines a solution for the problem to solve.
This issue requires input from the Product Designer to determine a UX proposal.
This issue includes a UX proposal that is up-to-date and has been validated.
This issue requires a technical proposal (e.g. link to the code to be changed), and it's added and up-to-date.
This issue could affect application performance, and the concern is explained in the issue description.
This issue could affect application security, and the concern is explained in the issue description.
This issue is the smallest iteration possible and doesn't require further break down.
This issue is linked to related, blocking and blocked issues, and it's up-to-date.
This issue is labeled correctly.
This issue requires PoC, prototype or Technical Evaluation due to its high complexity, and it's already finished.
This issue describes a list of tasks or expected merge requests, therefore the weight is set and needs weight label is removed.
If both backend and frontend work are required, add ~backend-weight::* and ~frontend-weight::* labels as well.
Starting from 16.0 you won't be able to filter environments by search parameter shorter than 3 characters in the REST API. API will return an error.
We're making this change because searching by the short environment name is very inefficient, especially in combination with other search options.
The environment_search_api_min_chars FF has been enabled for all projects on GitLab.com. With a 50% rollout, we saw no customers being impacted by this change: #387244 (comment 1241603417)
This will allow us to decouple feature deployment from feature activation on GitLab.com and thus announce a more accurate time period when breaking changes go live.
We currently don't have the information if this feature can be deployed behind a feature flag. Please add that information (if there is a feature flag and how is it called) here.